Money Bundle Laravel Package

Product Decisions This Supports

• Pricing and catalog work — multi-currency price lists, regional price books, and discount rules all rest on a single, correct money primitive. This bundle makes that primitive injectable across a Symfony app so pricing logic doesn't get re-implemented per feature team.
• Billing, invoicing, and subscription roadmap — line items, proration, tax, refunds, and credit notes are exactly where float arithmetic produces penny-level discrepancies that become finance tickets and audit findings. Adopting a Money value object is a prerequisite decision for any billing epic.
• Payouts and marketplace splits — allocating a total across N parties without losing or inventing minor units is a solved problem in moneyphp/money (allocate()), not something to hand-roll. This directly gates whether a split-payout feature is a two-week or a two-quarter build.
• Build vs. buy on the money layer — the recurring PM question "do we write our own Money class?" is answered here: no. The real decision narrows to how you integrate moneyphp/money, and this bundle is one of the cheaper options (declarative service wiring vs. hand-written container config).
• Platform/stack scoping — note the mismatch: this is a Symfony bundle, not a Laravel package. If the roadmap assumes Laravel, this package is out of scope and the decision becomes "use moneyphp/money directly with a hand-rolled service provider, or evaluate a Laravel-native integration." That is a scoping input, not an implementation detail.
• Framework baseline decisions — 6.4 now requires PHP 8.4+ and Symfony 7.4|8, and 8.0 will require Symfony 8.0. Teams on Symfony 6.4 LTS or early 7.x either upgrade the framework, stay on an older bundle line, or look at direct library use. This is now a concrete planning input for platform-upgrade roadmaps, not an implementation detail.
• Storage and API contract decisions — adopting Money forces an explicit choice on persisting minor units as integers vs. decimals, and on serializing amounts with currency codes. Those are product-visible API contracts that affect partner integrations and reporting accuracy.
• Localization/formatting scope — a bundle-level integration usually implies shared formatters (Twig filters, form types). That determines whether "show prices in the user's currency format" is a config change or a cross-cutting refactor.

When to Consider This Package

Consider it when:

• You are on Symfony 7.4 or 8.x with PHP 8.4+ — the current line requires both. This bundle is Symfony-specific; it does nothing for Laravel, and the brief's "Laravel/PHP" framing should be corrected before anyone evaluates it.
• Multiple services, modules, or bundles in the app need Money, and you want autowiring, a configured default currency, and one canonical place to change that default.
• Your team has already vetted moneyphp/money and is comfortable with its API. The bundle is an integration convenience, not the value itself.
• You are willing to accept bounded, cheap risk: the integration layer is thin enough that vendoring or replacing it with a few container definitions is a day of work, so single-maintainer/low-adoption signals don't block you.
• You want a small, MIT-licensed surface you can read end-to-end during review rather than a framework with its own opinions.

Look elsewhere when:

• You're on Laravel. Different integration entirely; evaluate moneyphp/money plus a Laravel service provider, or a Laravel-specific money package.
• You're on Symfony 6.4 LTS or an older 7.x with no near-term upgrade plan. 6.4 requires Symfony 7.4|8; you would be stuck on an older bundle line or adopting the library directly. Factor the framework-upgrade cost into any business case.
• You need non-decimal currencies, configurable scale, or richer arithmetic semantics — brick/money is the stronger choice there and has a healthier ecosystem.
• Your money needs are trivial — one currency, integers stored as cents, formatting only. A bundle is unnecessary ceremony; direct use of the library or plain integers is simpler.
• Procurement or security review requires multi-maintainer projects and demonstrated adoption. One star and zero dependents is a hard stop in regulated environments without an internal fork plan.
• You need enterprise support, SLAs, or a long deprecation policy.

Health read: last release 2025-12-20 shows recent activity — the strongest positive signal available. The 6.4.1 patch is a minor cleanup (removed an unused requirement), but the release notes carry meaningful roadmap information: a planned move to a new organization, a v8.0 rewrite described as "a more modern way," a Psalm → PHPStan migration across the maintainer's projects, and explicit PHP/Symfony baselines (6.4: PHP 8.4+, Symfony 7.4|8; 8.0: PHP 8.4+, Symfony 8.0). That is a stated modernization plan, which reads better than "abandoned" — but it is still a single-maintainer project with 1 star and 0 dependents. Read the source before adopting and assume you may own it. Budget an afternoon; the codebase is small enough to actually audit.

How to Pitch It (Stakeholders)

For executives (one paragraph): Money bugs are disproportionately expensive — a rounding error in pricing or payouts surfaces as customer credits, finance reconciliation work, and, in regulated contexts, audit findings. The underlying library, moneyphp/money, is the established PHP implementation of the standard Money pattern and is already the de facto choice in the ecosystem. This package is a thin Symfony integration layer on top of it: it registers the library's objects in the framework's dependency injection container so product teams use one correct money primitive instead of writing their own. The strategic commitment is to the library, not to this bundle — which is what keeps the risk small. The maintainer has published a modernization roadmap (organization move, v8 rewrite, tooling upgrade), which is a positive signal, though the bundle currently requires PHP 8.4+ and Symfony 7.4|8, so teams on Symfony 6.4 LTS need a framework-upgrade plan first. If the bundle stalls, replacing it is a contained engineering task measured in days, not a migration project. Recommendation: adopt the library as the standard, and treat the bundle as a convenience layer with a documented exit path.

For engineering (the practical case):

• It's a Symfony bundle wrapping moneyphp/money — the value is DI registration, autowiring aliases, and centralized configuration (default currency, formatters), not novel money logic.
• Mind the framework floor. 6.4 requires PHP 8.4+ and Symfony 7.4|8; 8.0 will require Symfony 8.0. If you're on 6.4 LTS you cannot take 6.4 without upgrading — either stay on a previous bundle line, use the library directly, or schedule the framework upgrade.
• Adoption cost is low and reversibility is high. Every service definition it provides can be reproduced in services.yaml if needed. Do not let it become a hard dependency in domain code — type-hint against Money\Money and Money\Currency from the library, never against bundle-specific classes. That single convention makes the exit path free, and it matters more now that a v8.0 rewrite is on the roadmap.
• Plan for the v8.0 rewrite. The maintainer has flagged it as a substantial modernization. Pin the version, commit a lockfile, and read the v8 changelog before jumping majors. With a single maintainer there is no guarantee of semver discipline.
• Do a source review before merge. With one star and zero dependents, "it works" has not been validated by anyone else. The upside is that the codebase is small enough to read completely.
• Watch the org transition. The project is moving to a new organization with the next version, and the maintainer's wider tooling is shifting (Psalm → PHPStan). Positive momentum, but expect a period of churn on URLs, package name resolution, and CI around that move — pin references now and update them after the dust settles.
• Flag the naming inconsistency (ph-il vendor, PhilMoneyBundle repo name) — minor, but it signals a personal/hobby project rather than a maintained one, and should set expectations about issue response times.
• If the product is Laravel, stop here: this package does not apply, and the equivalent decision is library-plus-service-provider, which is roughly the same amount of work.