Money Laravel Package

Technical Evaluation

Architecture fit. archtechx/money is a thin Laravel integration layer over brick/money, providing Eloquent casts and helpers so monetary values are stored as integer minor units and hydrated as value objects. For any Laravel service that touches pricing, billing, invoicing, or ledger data, this fits the "don't store money as float" architectural rule and removes the need for a bespoke cast per model. It is a library-level dependency, not an architectural commitment — it lives at the persistence/domain boundary and does not dictate application structure.

Integration feasibility. High. Adoption is additive: add the composer dependency, add a Money cast to existing columns, and migrate reads/writes. No service container bindings, no migrations published by the package, no queue/event infrastructure, no external service. The main effort is a data-shape decision (integer minor units + currency column) rather than integration plumbing. The v0.5.4 release adds Laravel 13 support only — no new API surface — so it changes the framework compatibility ceiling without altering the integration path.

Technical risk. Moderate, concentrated in two areas rather than in the release itself:

• Maturity risk: the package is pre-1.0 (v0.5.x). Semver permits breaking changes in minor bumps, so any upgrade must be treated as potentially breaking until v1.0. This is the dominant risk.
• Bus factor: the v0.5.4 change is authored by the primary maintainer. Contributor concentration is high; a stall in maintenance would leave us pinned to an older Laravel major. The release-specific risk is low: a single change (PR #30) that lifts framework support to Laravel 13, no deprecations, no behavioural changes to casting or formatting.

Key questions.

1. Which Laravel major are we targeting at rollout, and does our upgrade window for Laravel 13 align with the package's release cadence (v0.5.3 → v0.5.4 took one PR to close the gap — is that fast enough for our upgrade SLA)?
2. Is brick/money already a transitive dependency in our tree, or does this introduce a new value-object library we must standardise on?
3. Do we have existing float or decimal money columns that need a backfill migration, and what is the reconciliation story for those rows?
4. What is our blast radius if the package stalls before v1.0 — how many models and services would need to be refactored to drop the cast?
5. Does our currency set include any non-ISO or multi-currency-per-record cases that the cast's single-currency-per-column model does not cover?

Integration Approach

Stack fit. Native Laravel fit — Eloquent cast plus Composer install. No framework version constraint problems for our current stack, and v0.5.4 explicitly unblocks Laravel 13, which matters if the Laravel 13 upgrade is already on the roadmap. Compatible with standard Laravel testing (factories can set raw minor-unit integers), with API resources serialising via the value object's formatting methods, and with queue workers since there is no request-scoped state.

Migration path. Sequence as a bounded, reversible change:

1. Add the dependency and lock the version deliberately (see sequencing).
2. Pick a single low-risk model and column pair as a pilot — ideally a read-heavy, low-write table so rollback is cheap.
3. Backfill: convert existing decimal/float columns to integer minor units in a dedicated migration with a verification query comparing pre- and post-conversion totals.
4. Apply the cast, update serialisers and any Blade/API formatting to route through the value object rather than ad-hoc number_format calls.
5. Expand to remaining models once the pilot has run a full release cycle.

Compatibility. No breaking changes between v0.5.3 and v0.5.4 — the diff is framework support only. Existing casts, column definitions, and serialised output are unaffected. If we are on Laravel 11 or 12 today, v0.5.4 is a safe patch bump that also future-proofs the Laravel 13 upgrade; if we are already attempting Laravel 13, this release is the gating dependency.

Sequencing. Adopt v0.5.4 now as the pinned baseline rather than staying on v0.5.3, because it removes a known blocker for the Laravel 13 upgrade and carries no API delta. Constrain the Composer requirement to ^0.5.4 and treat every subsequent 0.x minor as a review-required upgrade, not an auto-merge. Land the package adoption in the same window as — or ahead of — the framework upgrade so we are not debugging two variables at once. Do not bundle the money-column backfill with the framework upgrade; those are separate releases with separate rollback plans.

Operational Impact

Maintenance. Low ongoing effort. No scheduled jobs, no config files to manage, no published assets. Maintenance surface is version pinning and periodic cast audits. The real maintenance obligation is governance: a documented rule that money columns are integer minor units and go through the cast, enforced in code review, otherwise the package's value erodes as ad-hoc formatting creeps back in.

Support. Upstream is a small, actively maintained open-source project with a responsive maintainer — evidenced by framework support shipping as a dedicated patch rather than languishing. Internal support burden is minimal: failures present as cast hydration exceptions, which are legible and traceable to the offending model. No vendor SLA; contingency is the fallback plan of a local cast wrapping brick/money directly, which is a contained, well-understood piece of work.

Scaling. Effectively neutral. The cast is CPU-only work on hydration and serialisation; integer storage is smaller and faster than decimal or string columns. No network hops, no external calls, no cache. At high read volume the cost is value-object instantiation per record, which is negligible relative to query time but worth noting for bulk-export paths that hydrate tens of thousands of rows — those should bypass the cast and read raw integers.

Failure modes.

• Currency mismatch: a record written with one currency code and read under a different configured currency surfaces as a runtime exception rather than silent corruption — fail-fast, which is the desirable behaviour, but it means bad data becomes a 500 rather than a wrong number. Needs a data-quality check before rollout.
• Pre-1.0 breaking change: a future 0.6.0 alters cast behaviour or signatures; without a pinned constraint this lands silently in CI. Mitigated by explicit ^0.5.4 pinning and a changelog review gate.
• Partial migration: mixed float and integer columns during backfill produce plausible-but-wrong totals. Mitigated by reconciling sums in the migration itself and gating the release on that check.
• Maintenance stall: package stops tracking Laravel majors, forcing a pin to an older framework. Mitigated by the local-cast fallback and by tracking the Laravel 13 support gap as a monitored risk.

Ramp-up. Low. One engineer can complete the pilot in under a day; the team-level learning is a single short walkthrough on minor-unit storage, the cast API, and formatting conventions. The bigger ramp-up cost sits with anyone writing reporting or export queries, who must know that the underlying column is an integer and that formatting belongs at the presentation layer — worth a short note in the engineering handbook.