Money Bundle Laravel Package

Technical Evaluation

What changed, and why it matters. v0.6.0 is not an incremental release. The single PR in the changelog ("Refactored to use brick/money") replaces the bundle's entire underlying value-object library: moneyphp/money is gone, brick/money is in. Every public surface this bundle owns — the DBAL type mapping, the DI service signatures, the Twig filters, the form types — is downstream of that swap. This is a breaking change wearing a minor-version number, which is permitted under 0.x semver but not signalled in the release notes (no BREAKING marker, no migration guide, no upgrade section).

Framing correction still stands. This remains a Symfony bundle, not a Laravel package: a thin integration layer over a money library, with no service provider, facade, Eloquent cast, or Blade directive. What changed is which library it wraps. The prior assessment's split — durable library beneath, replaceable glue above — is unchanged; only the identity of the durable library is now in question.

Architecture fit. For Symfony + Doctrine + Twig, fit is still structurally sound, but the swap rewrites the semantics your application sees. moneyphp/money is an integer-minor-units library: Money::USD(1999), immutable, allocation-safe, no rounding concept because there are no fractional units. brick/money is a decimal-and-scale library built on brick/math: Money::of('19.99', 'USD'), a Context carrying scale and rounding mode, RationalMoney for division, ISO currency metadata, and cash-rounding support. These are different data models, not different APIs for the same model. Adopting v0.6.0 is choosing decimal-string-with-context over integer-minor-units. For Laravel, fit remains poor by construction, and now additionally means depending on a library whose model differs from the one the previous assessment recommended you implement.

Integration feasibility. Unchanged in shape, changed in substance:

• Symfony shop already on 0.5.x: this is a re-integration, not an upgrade. Entity property types, DBAL column types, and Twig call sites all change. Treat it as a project with a data migration, not a composer update.
• Symfony shop starting fresh: viable, with the caveats below.
• Laravel shop: still do not install this bundle. But the prior recommendation — "install moneyphp/money directly and write ~100 lines" — now needs a deliberate library choice rather than a default. brick/money is a defensible pick if you want context-based rounding, ISO currency data, and cash rounding out of the box; moneyphp/money remains simpler and integer-native. Pick one, record why, and forbid the other via a composer conflict entry so a transitive dependency cannot introduce two money models into one codebase.

Technical risk. Elevated from the prior assessment, and the prior assessment's prediction has now materialized: it flagged "unpinned upstream release changing DBAL type behavior on a routine composer update" as a failure mode; v0.6.0 is that failure mode, at a larger blast radius than anticipated. Additional risk factors:

• Bus factor still one. A single-author refactor of the core abstraction with no migration notes is a maintenance-discipline signal, not just a code change.
• New platform requirement. brick/money depends on brick/math and requires ext-bcmath or ext-gmp. Verify both against your base images, CI runners, and any shared hosting or serverless targets. This is an environment change, not just a Composer change.
• Storage format is now a live question. The amount-storage answer under 0.5.x (integer minor units) does not automatically carry over to a decimal-scale library. If the DBAL type now persists decimal strings, existing integer columns are incompatible.
• Provenance unchanged. Still 4 stars, 0 dependents, single maintainer, no security disclosure process. The release metadata remains unverified until you confirm a signed tag, a Packagist artifact, and a changelog beyond a single PR line.

Key questions to resolve before any commitment.

1. Does the DBAL type persist integer minor units or decimal strings with scale, and is the v0.5.x → v0.6.x column format compatible? If not, what is the migration?
2. Which brick/money, brick/math, and doctrine/dbal majors are supported by the tagged constraint set, and which Symfony majors?
3. What Context does the bundle register by default — scale and rounding mode — and can it be overridden per service, per currency, or per operation? Defaults here silently become your accounting policy.
4. How are null amounts, negative amounts, and zero-decimal (JPY) and three-decimal (BHD, KWD) currencies handled by the type and the Twig filter?
5. Is RationalMoney exposed for allocation and proration, or does the bundle force premature rounding at intermediate steps? (Intermediate rounding is the classic source of split-payment drift.)
6. Is there a CI matrix spanning PHP and DBAL versions, or one passing badge?
7. Is there any stated support window for 0.5.x, or is the previous line effectively abandoned?

Integration Approach

Stack fit. The layering advice is unchanged and now more important: treat the library as the dependency and the bundle as optional glue. Which library is a decision you should make explicitly, not inherit from a bundle's release cadence.

Decision rule.

• Standardizing on Symfony + Doctrine → the bundle is a reasonable convenience layer; pin it hard.
• Any non-Symfony stack → implement the integration yourself against your chosen library.
• Already on 0.5.x with production data → do not absorb v0.6.0 opportunistically. Schedule it, and only if you have a reason to prefer brick/money's model.

Migration path (0.5.x → 0.6.0, Symfony).

1. Freeze the current version with an exact constraint (0.5.1, not ^0.5) so a routine update cannot land the swap.
2. Confirm ext-bcmath/ext-gmp availability across every environment before writing code.
3. Stand up a spike branch: register the new bundle, define the default Context, and round-trip a representative slice of real amounts through the DBAL type.
4. Decide storage format explicitly. If v0.6.0 writes decimal strings, plan an additive column, dual-write, and a reconciliation job — the same backfill pattern as before, run in the opposite direction.
5. Port presentation and business rules separately. Rounding and allocation semantics changed libraries; do not assume the old policy carries over.
6. Cut reads over, verify totals against the 0.5.x system at the aggregate level (sum by currency by day), then remove the old column and the old library.

Migration path (greenfield / Laravel).

1. Choose the library, record the rationale in an ADR, add a composer conflict against the other.
2. Introduce a cast/value-object boundary at the persistence edge; forbid raw float for currency.
3. Backfill legacy DECIMAL/float with an explicit rounding mode; keep the legacy column readable during a dual-read window.
4. Dual-write for one release cycle with a nightly reconciliation diff that fails loudly.
5. Presentation last-but-one, business rules last.

Compatibility. Pin to an exact version or commit for anything 0.x, and write the reason in composer.json. Do not express this dependency as ^0.6 — the next refactor will arrive the same way this one did. If you later add a Symfony service alongside a non-Symfony stack, re-evaluate the bundle then; do not adopt it now for anticipated future fit.

Sequencing. Environment prerequisites → library/library-boundary decision → storage format → backfill/reconcile → presentation → business rules (rounding policy, allocation) → observability. Rounding policy must land in its own change with its own review; it is the thing that produces incidents.

Operational Impact

Maintenance. Assume you own the code regardless of adoption. If you adopt, vendor or fork into your monorepo and pin the commit; do not rely on upstream responsiveness, and do not rely on the release notes to tell you a breaking change happened — 0.6.0 did not. Budget re-verification work on every brick/math, brick/money, Doctrine DBAL, and Symfony major, plus the PHP extension baseline.

Support. Unchanged: no vendor, no SLA, no community of scale. A 4-star, 0-dependent repo means the issue tracker is one person's inbox, and there is no downstream population to surface bugs before you do. The real support artifact is internal documentation of the currency storage format, the Context defaults, and the rounding policy — that document is now out of date and must be rewritten.

Scaling. Runtime cost stays negligible; both libraries are CPU-bound arithmetic. Two scaling risks are now live:

• Data integrity at volume. The library swap changes how intermediate division and allocation behave. A wrong rounding mode is invisible at 100 rows and a finance incident at 10 million, and correcting minor-unit or scale drift after the fact is a reconciliation project, not a bug fix.
• Model fragmentation. The realistic worst case is a codebase with some services on moneyphp/money and some on brick/money, converting at boundaries. Conversions between the two are lossless only if nobody rounds in between — and someone always rounds in between.

Failure modes to watch.

• A composer update on a ^0.5 constraint silently landing v0.6.0 in a staging build. This is the top risk and it has already happened once in the wild.
• Existing integer minor-unit columns read by a decimal-scale type, producing 100× errors.
• Default Context scale and rounding mode inherited without review, silently setting accounting policy.
• Intermediate rounding before allocation, dropping remainders and breaking split payments, tax, and proration totals.
• Locale formatting divergence between PHP and the frontend (comma vs. dot separators in API payloads).
• Zero-decimal currencies rendered with two decimals; refunds off by 100×.
• Missing ext-bcmath/ext-gmp on one environment class — passes locally, fails at deploy.
• Lossy conversion at a boundary between two coexisting money libraries.

Ramp-up. A mid-level engineer is productive with either library in a day; both APIs are small and documented. The bundle remains a thin, non-obvious layer costing a second mental model. Reserve the real ramp-up for the money domain — rounding policy, allocation, tax — and add a short internal note on which library the codebase uses and why, since "the money library" is no longer a stable phrase in this codebase.

TPM recommendation (revised). The recommendation to not make this bundle a strategic dependency is unchanged and is now better supported: v0.6.0 demonstrates that a 0.x, single-maintainer bundle will rewrite its foundational abstraction without a migration guide, and your integration cost is set by that decision, not by yours. Choose the underlying library deliberately — brick/money if you want context-based rounding, ISO currency data, and cash rounding; moneyphp/money if you want integer-native simplicity — own the ~100–150 lines of integration your stack actually needs, pin exactly, and forbid the unchosen library at the Composer level. Revisit the bundle only if the organization standardizes on Symfony with Doctrine. The opportunity score of 15.94 and 0 dependents still point the same direction: this is low-leverage glue, and the value lives in the library beneath it — a library you should now pick on purpose rather than by inheritance.