Money Bundle Laravel Package

Technical Evaluation

Architecture fit — unchanged: still poor for a Laravel target. v6.4.1 is a dependency-hygiene patch (Remove unuse requirement); it does not alter the package's shape. It remains a Symfony bundle — a Bundle subclass, a DI extension with a configuration tree, and optional Twig/Doctrine/formatter wiring — none of which is reachable from a Laravel ServiceProvider. The new release notes confirm rather than soften this: the roadmap is expressed entirely in Symfony terms (Symfony 7.4|8, then Symfony 8.0), so the maintainer's investment is going into the framework glue we cannot use. The package still resolves, in a Laravel context, to "moneyphp/money plus dead code."

Integration feasibility — unchanged: low as-is, high if decoupled. The release notes are pure roadmap and requirement bookkeeping; no new integration surface, no bridge, no framework-agnostic core. Decoupling remains the only sane path: require moneyphp/money directly.

Technical risk — the vendor risk is now higher, not lower, despite a more active maintainer.

The release notes are the substantive change here. They are not release notes for a patch release; they are a forward plan embedded in a bugfix tag, and they materially sharpen three of our earlier concerns:

Net: the maintainer is more engaged than the prior assessment credited, and the roadmap shows intent. But engagement in the wrong framework plus an unversioned rewrite plan plus an org migration adds churn risk without adding a single capability we can consume. The underlying moneyphp/money recommendation is untouched.

Key questions to close before any decision

• What is the effective composer.json at 6.4.1 — is the PHP 8.4 / Symfony 7.4|8 floor already enforced, or merely announced? A patch tag that mixes a manifest fix with a future requirement statement is a documentation-accuracy smell worth one composer show to resolve.
• Which requirement was "unused," and was it load-bearing for any optional integration? Confirm the fix did not silently drop a capability.
• Where is the new organization, what is the Packagist vendor name post-move, and will the old name be abandoned, redirected, or squatted? Security-advisory routing for a payments-adjacent package depends on this.
• Does the v8 rewrite have a stated deprecation policy, changelog discipline, or migration path — or is "lots of rewrite" the entire plan?
• Is there a CI matrix today, and does it gate the PHP 8.4 floor and the current moneyphp/money major? phpStan "in version 8" implies no static analysis gate now.
• Does the bundle still contain non-trivial domain logic (rounding strategies, allocation, cash rounding, currency persistence types) that we would otherwise have to reproduce? This remains the only question that could change the recommendation.
• Any stated deprecation or support policy for the pre-8 line, given v8 is described as a rewrite?

Integration Approach

Stack fit. Unchanged and unaffected by this release. moneyphp/money fits our stack (immutable value objects, integer minor units, pluggable bcmath/gmp arithmetic, no framework coupling). The bundle does not fit, and v6.4.1 gives us no new reason — or mechanism — to bring it in.

Recommended path. Do not adopt ph-il/money-bundle. Adopt moneyphp/money directly behind a thin internal adapter:

1. A MoneyServiceProvider binding a configured MoneyFactory and an application currency context.
2. An Eloquent cast persisting { amount: minor units as string, currency: ISO 4217 } into two columns — never a float column.
3. A validation rule and a request-cast for inbound monetary input.
4. A JSON resource/serializer contract emitting minor units plus currency code, explicitly documenting that the API does not emit decimals-as-floats.
5. A Blade/formatter helper for display, with locale-aware formatting kept out of the domain layer.

One to two days of build, and a smaller surface than the bundle would have provided even in Symfony. Note the roadmap reinforces this: pinning a bundle whose next major is a self-described "lots of rewrite" means our adapter would be the stable layer regardless.

Migration path. Still greenfield — 0 dependents, no internal adoption. The v8 rewrite slightly improves our position: there is nothing of ours to migrate, and no upstream API we have bet on. If a Symfony service using the bundle is ever acquired, plan for it to be stranded on the pre-8 line; the bundle's config is small by construction and can be inlined while keeping moneyphp/money pinned.

Compatibility gates.

• Confirm moneyphp/money's supported PHP range against our Laravel runtime (Laravel 10/11/12 imply PHP 8.1/8.2+). Irrelevant to the bundle decision, but relevant to which moneyphp major we pin.
• New: treat the bundle's PHP 8.4+ / Symfony 7.4|8 floor as dispositive if any Symfony-adjacent team asks about reuse — it cannot coexist with Laravel-typical PHP 8.2/8.3 runtimes.
• Confirm ext-bcmath or ext-gmp in every environment, including CI and container images — still the most common silent failure.
• Use BIGINT or string columns for minor units, not INT.
• New: record the org move in our dependency register now (vendor name, repo URL, advisory channel), so a future audit does not flag the package as unmaintained-by-disappearance.

Sequencing.

1. One-day spike: install the bundle in a throwaway Symfony skeleton purely to read what it wires up, and diff that against the adapter sketch. Do this against a pre-6.4 tag if the PHP 8.4 floor blocks the skeleton — and treat that workaround as one more data point.
2. Decision gate: if the spike finds non-trivial domain logic (rounding, allocation, cash rounding) worth lifting, lift it into our adapter under our license and tests; otherwise proceed with the plain library.
3. Build and test the adapter against a pricing/ledger bounded context.
4. Roll out to one service, then standardize via an internal starter template.
5. Optional, low priority: re-read this package's changelog at v8.0. If the rewrite produces a framework-agnostic core, reassess from scratch — that would be the first release worth evaluating on its merits.

Operational Impact

Maintenance. Whoever adopts this bundle owns it, and v6.4.1 makes that ownership more expensive, not less. The roadmap commits to: an org migration, a static-analysis toolchain swap, a PHP floor jump, and a self-described "lots of rewrite" — all in the next two majors, all announced without dates, deprecation policy, or migration guidance. With one maintainer and no dependents, none of that lands on a schedule we can influence. A ~200-line adapter we wrote is still strictly less maintenance: its blast radius is code we can read in one sitting, and it has no upstream roadmap at all.

Support. No vendor, no SLA, no advisory channel we can currently name — and the advisory channel is about to move, with the new org not yet stated. For payments-adjacent code that is a governance gap, and it remains the strongest single argument against adoption. The phpStan commitment is a genuine positive signal about intent; it is not a support commitment.

Scaling. Performance remains a non-issue — thin wrappers over integer arithmetic; throughput is dominated by our own DB and serialization choices. The thing that does not scale is organizational coupling to an integration layer with an unannounced rewrite on its roadmap. Library-plus-shared-internal-package scales fine.

Failure modes to design against.

• Float contamination in persistence or the API layer, producing cent-level drift that reconciles only at month-end.
• Rounding-mode divergence between cart, tax, and ledger paths; enforce one configured RoundingMode and assert it in tests.
• Currency mismatch exceptions surfacing as 500s at checkout; map to domain errors early.
• Serialization that drops scale or currency, breaking downstream consumers silently.
• Revised: Composer updates pulling a moneyphp/money major into a build with no integration tests — now compounded by an upstream v8 rewrite that may change both its own API and its dependency constraints at once.
• New: Org-move breakage — renamed vendor namespace, stale repo URL, mirrored or abandoned old package name, and security advisories filed against a repository nobody is watching.
• New: A requirement declared in a patch release ("6.4 will require PHP 8.4+") whose actual enforcement point is unclear; any team that does try the bundle can hit an unsatisfiable platform requirement with no clear changelog entry.
• Missing bcmath/gmp in a new environment failing at first monetary operation rather than at boot.

Ramp-up. Unchanged and low: the Fowler Money pattern is well documented, moneyphp/money has a clear API and active user base. Budget half a day per engineer, plus a short alignment session with finance on rounding, allocation, and cash-rounding rules. That conversation is where the real risk sits, and no package in this space — bundle, library, or rewrite — will have it for us.

Bottom line. v6.4.1 does not change the recommendation, and it slightly strengthens it. The release is a manifest-hygiene fix carrying a roadmap: an org move, a PHP 8.4 / Symfony 7.4|8 floor, a linter swap, and an announced v8 rewrite, all with no dates, no deprecation policy, and still zero downstream users to validate any of it. That is more maintainer activity in a direction we cannot consume, attached to more churn than we want in a payments path. Reject the bundle; standardize on moneyphp/money behind a small internal adapter we control. Score holds in the low-3s — the maintainer's intent is now visibly better, but the deliverable is still a single-maintainer, zero-adoption, wrong-framework wrapper whose next two majors are explicitly unstable.