Laravel Currency Casting Laravel Package

Technical Evaluation

Architecture fit. This is a narrow, single-purpose package: an Eloquent cast that maps an integer column to a Money object on read and back to an integer on write. Architecturally it is a presentation/serialisation-layer concern, not infrastructure — it touches model attribute access, not request lifecycle, queue consumers, or service-provider boot order. That makes it low blast radius and easy to reason about, but it also means the package's value is entirely determined by two questions a TPM should escalate immediately: which Money library it wraps (brick/money, moneyphp/money, or a bespoke value object), and whether it exposes a proper Money object or a raw float. The description is ambiguous ("casts … to floats automatically" versus "work with Money objects"). For any product handling money, float arithmetic in application code is a correctness risk, not a style preference, so this distinction drives the adopt/hold decision more than anything else in the repo.

Integration feasibility. Trivially installable on any Laravel app already storing minor units as integers. The realistic adoption is incremental — apply the cast to one or two models, verify formatting and rounding match current behaviour, then widen. The awkward case is greenfield schema design: if the team is choosing storage format now, this package presumes integer minor units, which is the right default but should be an explicit decision, not inherited from a package. The non-trivial case is retrofitting an app that stores decimals or strings — that is a data migration, not a cast change, and should be scoped separately.

Technical risk.

• Adoption/track-record risk (high). Five stars is essentially no community validation. A single-maintainer package with a small user base has an unquantified bus factor. For a ~100-line utility, the cost of in-housing is low, which materially weakens the buy case.
• Float-vs-Money ambiguity (high). If reads return floats, arithmetic and comparison will drift on rounding, and any serialised output changes type. Must be resolved before adoption.
• API contract change (medium). An Eloquent cast changes toArray()/toJson() output. If an API currently serves integer cents and starts serving 12.34, that is a breaking consumer change hiding inside a "refactor."
• Constraint semantics of v1.11.0 (medium). Confirm whether Laravel 13 support is additive (11/12/13) or a narrowing. A narrowing freezes Laravel 11/12 consumers on v1.10.x with no further fixes.
• Rounding and currency policy (medium). How are half-cent values, negative amounts, and per-attribute currency codes handled? Global config currency versus per-model currency is a design decision the team must own.

Key questions for the maintainer.

1. Which Money library does the cast return — a value object or a plain float?
2. Is the stored integer assumed to be minor units (cents), and is that documented and enforced?
3. How is rounding handled on write, and is it configurable?
4. Can currency code be set per attribute/model, or only globally?
5. What is the minimum PHP version, and did v1.11.0 raise it?
6. Does v1.11.0 keep Laravel 11/12 in the constraint, or narrow to 13?
7. Is the Laravel 13 lane actually covered in CI, or only declared in composer.json?

Integration Approach

Stack fit. Fits any Laravel app with monetary attributes stored as integers. It is a convenience layer, not a dependency that other parts of the system build on, so it can be adopted or removed per-model with minimal coupling. Treat it as an optional ergonomics improvement, not an architectural commitment.

Migration path. Additive and reversible if storage is already integer minor units — add the cast, run the host app's suite, ship. If the app currently stores decimals or formatted strings, stop: that is a data-model migration with backfill and reconciliation, and should be its own initiative with its own budget. Separately, upgrading the package to v1.11.0 is a low-risk patch bump that removes it from any Laravel 13 blocker list — schedule it on normal dependency cadence, not as a project.

Compatibility. Verify against actual locked versions, not the README: PHP floor in the runtime image, laravel/framework, and the Money library if the team already depends on one (version conflicts here are the likely Composer failure). Check whether the package's CI actually tests the Laravel versions the team runs. And audit serialisation: anything consuming these models over JSON must be checked for type changes.

Sequencing.

1. Resolve the float-vs-Money and rounding questions (questions 1–3) — a short check that gates everything else.
2. Prototype the cast on one low-traffic model in a non-production environment; diff toArray() output before and after.
3. Confirm no API consumers break on the serialisation change; update contracts or add a transformer if needed.
4. Bump the package to v1.11.0 independently of any framework work.
5. Widen the cast to remaining models, with reconciliation tests against existing stored values.

Operational Impact

Maintenance. Ongoing cost is near zero if adopted — the package has no runtime footprint. The real consideration is ownership: a five-star, single-maintainer dependency is a candidate for in-housing precisely because reimplementing an integer-to-Money cast is small and removes the bus-factor risk entirely. If the team's dependency policy has a minimum-adoption or maintainer-redundancy threshold, this package likely fails it, and the build-vs-buy decision should be made deliberately rather than defaulted.

Support. The realistic ticket class is "the number displayed or persisted differs from what we expected" — a rounding or units-mismatch bug. That is a host-app debugging problem, and the team should own the domain knowledge (minor units, rounding policy, per-currency rules) rather than lean on a small upstream. Establish whether the maintainer treats rounding discrepancies as in-scope bugs; assume not.

Scaling. No scaling implications. The cast is per-attribute and allocation-cheap; it does not touch query patterns, memory, or throughput at any meaningful volume.

Failure modes. Ranked by likelihood:

• Units/rounding mismatch (most likely). A column holding cents is treated as units, or vice versa, producing silent 100× errors. Mitigation is explicit documentation and reconciliation tests, not package features.
• Serialisation break (likely). JSON output changes type, breaking downstream consumers. Mitigation is a contract diff before rollout.
• Money-library version conflict (moderate). Composer cannot resolve the package alongside the team's own money library. Mitigation is checking the dependency early.
• Maintainer abandonment (moderate over time). Small user base plus single maintainer; the mitigation is a documented in-house fallback, which for this package is a day of work.
• Constraint narrowing in v1.11.0 (low). Laravel 11/12 support dropped, forcing a coupled framework-and-package upgrade. Mitigation is question 6.

Ramp-up. Near zero — engineers already comfortable with Eloquent casts need no new concepts. The knowledge investment is in the money domain (minor units, rounding, per-currency formatting), which the team should own regardless of whether this package is adopted.