Laravel Floats Laravel Package

Product Decisions This Supports

• Schema/feature decisions that hinge on numeric precision. Any roadmap item where a column must be a true MySQL FLOAT (4-byte single precision) rather than DECIMAL or DOUBLE — telemetry/measurement readings, sensor data, approximate geospatial coordinates, percentages — depends on being able to express that intent in a migration. This package is the enabler for that one decision.
• Build vs. buy for a micro-capability. The "buy" side of the analysis is effectively a one-line Composer dependency under MIT. The honest framing for the team is: this is a ~20-line macro, so the real question isn't "buy or build," it's "do we want a third-party dependency at all for something we could inline in five minutes?"
• Schema-parity / integration decisions. If you're mirroring an external system's schema (legacy DB, partner API, data warehouse export) that mandates FLOAT columns, this package removes friction from that migration. That's a legitimate but narrow integration decision.
• Migration ergonomics as a feature-quality lever. It supports the decision to keep schema definitions expressive and portable across environments rather than falling back to raw DB::statement() calls that bypass the schema builder and are harder to review.
• Not on the roadmap: nothing here is a strategic bet. It's infrastructure hygiene, not a differentiator.

When to Consider This Package

Consider it when:

• Your target column genuinely needs single-precision FLOAT semantics and you want it declared through Laravel's Blueprint API.
• Your Laravel version's schema builder doesn't expose a float() method that produces what you need, and you want a drop-in macro rather than hand-rolled SQL.
• You're maintaining schema parity with an external or legacy system that specifies FLOAT.
• You've done the license and supply-chain check — MIT, single maintainer, tiny surface area, easy to vendor or fork if abandoned.

Look elsewhere / skip it when:

• Your Laravel version already supports float() natively — verify this first; if it does, the package's value proposition largely evaporates and you're adding a dependency for nothing.
• The column is money or anything that must be exact — use DECIMAL; FLOAT is the wrong tool and no package fixes that.
• You're uncomfortable with an 11-star, single-maintainer dependency in the migration path; a one-off DB::statement() or a local macro in AppServiceProvider is a lower-risk equivalent.
• You need multi-database support, migrations testing, or any maintenance guarantees — this package makes no such promises, and a star count of 11 is a reasonable proxy for "no community backstop."

How to Pitch It (Stakeholders)

For executives: This is a tiny, free, MIT-licensed utility that lets our migrations declare MySQL FLOAT columns directly. It's not a platform decision or a cost centre — it's a five-minute unblock for one narrow schema need. The strategic value is near zero; the cost and risk are also near zero. Approve it as routine tooling, not as an initiative.

For engineering: Treat it as a candidate, not a default. Confirm whether our current Laravel version already covers this natively before adopting; if not, the package is a clean one-liner, but a local macro gives us identical behaviour with one fewer dependency and one fewer abandonment risk. If we do adopt it, pin the version, note the maintainer in the dependency register, and be ready to vendor the macro if the package goes quiet. Recommendation: evaluate-native-first; adopt only if we can't get FLOAT cleanly otherwise.