Money Bundle Laravel Package

Product Decisions This Supports

• Money-as-a-value-object architecture. The package's real value is not the bundle wiring but the underlying moneyphp/money domain model: amounts stored as integer minor units plus a currency code, never floats. This is the decision that shapes schema design (amount BIGINT + currency CHAR(3)), API contracts (return {amount: 1999, currency: "EUR"} or a formatted string, not 19.99), and downstream reporting.
• Multi-currency and localization roadmap. Whether to support more than one currency, charge in the buyer's currency, or display localized formatting. A bundle like this signals that currency handling is treated as infrastructure, not a formatting concern bolted onto views.
• Rounding and allocation policy — the decision most likely to cost real money if made implicitly. Splitting an invoice across line items, prorating a subscription mid-cycle, or distributing a discount requires an explicit allocation strategy (largest-remainder, per-item rounding) and a documented policy on where rounding residue lands. Any money library forces this conversation into the open, which is the main PM-visible benefit.
• Build vs. buy on the adapter layer. This package is a thin Symfony DI/config wrapper (service definitions, parameter config) around a mature library. The buy decision should be scoped to the library; the wrapper is 100–200 lines of your own code in any framework.
• Feature scope for pricing, invoicing, and payouts — tax-inclusive vs. tax-exclusive display, FX conversion points, refund and store-credit arithmetic, and whether stored historical amounts need to be reproducible after a currency or rounding rule changes.

Update from v1.3.0: the release adds Symfony 5.x support. This is a compatibility bump, not a capability change — no new domain features, no API/behaviour changes, no deprecations. It narrows the framework-compatibility caveat below but does not alter any of the product decisions above, and it does not touch the license, maintenance, or adoption signals.

Important framing correction: this is a Symfony bundle, not a Laravel package. It does not ship a Laravel service provider, facade, validation rules, Eloquent casts, or config publishing. For a Laravel codebase it is reference material, not a dependency.

When to Consider This Package

Consider it only if all of the following hold:

• The application is Symfony, not Laravel.
• You are on Symfony 5.x (explicitly supported as of v1.3.0) or Symfony 4.x; for Symfony 6/7, expect to verify compatibility or patch service definitions yourself.
• You want currency services auto-wired from config/packages/*.yaml and are content to inherit the bundle's conventions for default currency and parser/formatter selection.
• Your legal/procurement process does not require a confirmed OSI license — the metadata is NOASSERTION, meaning the license could not be determined from the repository. For a distributed or commercial product, treat this as a blocker until a human reads the LICENSE file.

Look elsewhere — specifically at moneyphp/money directly — if any of these are true:

• Laravel or framework-agnostic PHP. Write a small service provider, an Eloquent cast (AsMoney), and a money validation rule yourself. A day of work, no framework coupling, no abandoned dependency.
• Maintenance is a requirement. The v1.3.0 Symfony 5.x bump is a narrow compatibility patch, not evidence of a maintained release cadence: still a single-maintainer project with zero dependents and ~22 stars, and it carries no security-response or PHP 8.x compatibility commitment. Confirm the release date and recent commit activity before treating it as "alive."
• You need customization of rounding, allocation, or currency metadata (crypto, custom ISO lists, historical rates) — you will be overriding the bundle's configured services anyway, which negates the reason to adopt it.
• Supply-chain or audit review — an unlicensed, thinly maintained transitive dependency is a poor trade for saving a few dozen lines of container configuration.

How to Pitch It (Stakeholders)

Recommendation: do not adopt this package. Adopt the pattern and the underlying library.

To executives: There is a widely used, well-tested open-source library that eliminates an entire class of money bugs — rounding drift, floating-point errors on totals, and currency mix-ups in reports. This particular package is a small Symfony-specific wrapper around it. The latest release only adds Symfony 5.x support — a compatibility patch, not a sign of renewed investment. It still has no downstream users and an unclear license, so it saves roughly a day of setup while introducing a maintenance, licensing, and security-review obligation we would carry indefinitely. Our proposal: take the library directly, keep the integration code in-house (small, framework-native, testable), and spend the saved risk budget on the decisions that actually move revenue — multi-currency support, tax display, and a documented rounding policy.

To engineering: The value is in the domain model — integer minor units plus currency, explicit allocation, no floats anywhere in the pricing path. This bundle only adds Symfony container wiring; v1.3.0 merely widens that wiring to Symfony 5.x. In our Laravel codebase that wiring is a service provider, an Eloquent cast, and a validation rule. Estimated effort: 1–2 days including tests, versus adopting a dependency we would end up forking.

Risks if we adopt anyway: thin, single-maintainer activity where the only recent signal is a framework-version bump; no confirmed license; continued compatibility work on modern framework versions; and the strong likelihood we override most of its configuration within a quarter, leaving a dependency that provides no remaining benefit. Score signal is also weak — low overall score, no dependents — which is consistent with a personal/experimental project rather than production infrastructure.