padam87/money-bundle
A Symfony bundle that integrates moneyphp/money, providing Doctrine mapping types, form types, and Twig helpers for storing, formatting, and working with monetary values and currencies safely in your application.
brick/money, not moneyphp/money. The decision it informs is unchanged in shape (write your own container wiring, form types, validators, and formatters, or adopt a thin bundle that already does it), but the dependency you are standardizing on has changed underneath the bundle.brick/money ships with explicit rounding strategies, money allocation/splitting, multi-context containers, and an exchange-rate plumbing layer — meaningfully more capability than the thin value object the previous assessment assumed. That is a roadmap input, because it changes what "supports multi-currency" costs.moneyphp/money payloads and any Money/Currency type-hints on our side will not survive the swap. Contracts that only carry integer minor units + ISO 4217 code do survive.brick/money makes rounding policy explicit and configurable rather than implied, which is good for tax-inclusive display and discount math, and is a reason to lock the policy down before the catalog grows.brick/money exposes exchange-rate and base-currency provider interfaces — but it remains a product policy question (when rates are captured, rounding at display vs. settlement, disclosure). Do not let the availability of plumbing get read as "FX is free."0.x dependencies at all. The mitigating factor is Composer's own semantics: ^0.5 will not auto-upgrade to 0.6.0, so this lands only if we opt in — pinning discipline is doing real work here.brick/money directly with ~50 lines of Symfony service config, (b) adopt this bundle as thin glue behind our own façade, or (c) stay on the legacy 0.5.x line. This release materially strengthens case (a).Consider it when:
brick/money. That is now a hard prerequisite — the bundle no longer has anything to do with moneyphp/money, and any doc, ticket, or architecture note that says otherwise must be corrected.brick/money's richer semantics (rounding strategies, allocation/splitting, money contexts) without writing the Symfony form type, validator, and formatter wiring yourself.brick/money + brick/math — verify against your platform matrix before committing, as this is a different baseline than the previous dependency.MoneyFactory / PriceFormatter façade, with no direct Padam87\MoneyBundle\* imports outside that boundary. This release is the argument for that boundary, not a hypothetical.0.x.Look elsewhere when:
moneyphp/money version. There is no in-place upgrade path — this is a primitive swap, not a bump. Either stay pinned on 0.5.x (accepting an effectively unmaintained line), fork, or budget a real migration across value objects, form types, validators, and any serialized Money payloads.moneyphp/money. Adopting this now means teaching the team a different library under a bundle name that used to mean the other one. Naming confusion is a recurring tax.brick/money directly.0.x bundle that just swapped its core dependency will not pass procurement; budget for owning the code.brick/money provides the exchange-rate interfaces; it does not provide rates, a rate-capture policy, or settlement logic. If you read the new plumbing as "FX solved," you will under-scope it.To executives (one paragraph): This is a small, free, open-source connector that makes a well-established PHP money library work cleanly inside our Symfony application. It does not process payments and does not hold customer funds — it standardizes how we represent and display prices so we stop losing money to rounding errors and stop rebuilding currency logic in every feature. Two things changed since our last review, and both are cheap to act on now. First, the connector switched the underlying money library to one that is arguably a better fit (explicit rounding rules, currency-conversion hooks); second, that switch was a breaking change made by a single volunteer maintainer, which is exactly the vendor risk we flagged. The decision stands as low-cost and reversible — roughly a day of integration on a greenfield feature versus one to two weeks of custom work — but it is now only sensible for new work, not for retrofitting existing code, and only if we keep it behind our own internal interface so we can drop or replace it without touching product code.
To engineering (summary): Treat v0.6.0 as a new dependency wearing an old name. It is Symfony glue over brick/money (requires PHP 8.1+, pulls brick/math), not over moneyphp/money; ^0.5 won't auto-upgrade to it, which is the only reason this is safe. Decision: adopt it only for new/greenfield surfaces, and only after confirming our platform supports the new baseline. Wrap its services immediately in our own PriceFormatter / MoneyFactory façade and forbid Padam87 imports outside that boundary. Store amounts as integer minor units plus an ISO 4217 currency code, never floats — that choice is what makes a future primitive swap a day of work instead of a schema migration. On the existing 0.5.x/moneyphp code: do not migrate opportunistically; the cost is value objects, form types, validators, and every serialized Money payload, so it needs its own ticket and its own estimate, and "stay pinned and eventually fork" is a legitimate answer. Pin exact versions, watch the release feed, and confirm that if we ever need FX, brick/money gives us providers but not rates or policy — that remains a separate vendor decision.
How can I help you explore Laravel packages today?