Money Bundle Laravel Package

Product Decisions This Supports

• Standardizing money as a value object (build vs. buy, at the modeling layer). The real decision this package surfaces is whether money gets a first-class type — an integer amount in minor units paired with an explicit ISO 4217 currency — or stays a float/bare DECIMAL column. That is an engineering standard with product consequences: it is the difference between billing totals that reconcile and totals that drift by a cent under load. The package is a thin Symfony DI wrapper around mathiasverraes/money, which encodes Fowler's Money pattern; the pattern is the durable asset, the wiring is not.
• Pricing, billing, invoicing, refunds, payouts, and multi-currency reporting. Any roadmap item touching per-currency pricing, tax-inclusive totals, proration, discount distribution, or locale-aware display benefits from integer-minor-unit arithmetic and currency-scoped operations that refuse to silently mix currencies. This is the class of decision the package nominally exists to serve.
• Making rounding and allocation policy an explicit product rule. Splitting an order total across line items, distributing a discount, or computing per-line tax forces a choice of rounding mode and remainder-allocation strategy. The underlying library exposes allocate and rounding modes explicitly, which converts a silent correctness bug into a documented rule a PM can sign off on with finance. This is the single highest-leverage product outcome in the whole evaluation.
• Reframing the question correctly. This is not a Laravel package and not a feature decision. It is a Symfony 2.x bundle with no business logic, no persistence layer, no FX source, and no HTTP surface. So the PM-level decision is not "should we adopt this" but "do we want the pattern, and do we want to own this wrapper."
• Legacy portfolio triage. Its presence in a dependency list is evidence that a service is running on an EOL framework generation. If that service is on your books, the decision is extend / freeze / migrate — and this package's abandonment is an input, not a decision of its own.
• Explicitly not supported: anything Laravel. No service provider, no facade, no config publishing, no package autodiscovery. A roadmap item premised on dropping this into a Laravel app rests on a category error and should be corrected before it reaches planning.

When to Consider This Package

Consider it only if all of the following hold:

• You are maintaining an existing Symfony 2.x application that already depends on the mathiasverraes/money API surface and already injects currency services from the container.
• You genuinely benefit from having Money value objects pre-registered as container services across many bundles and would otherwise duplicate that wiring.
• The application is in sustain/freeze mode — no active feature development, no new money-handling surfaces.
• You have accepted the Symfony 2 EOL risk on its own terms, independent of this package.
• Someone has read the source (it is small — expect a handful of service definitions) and verified the fork's composer.json name, branch, and divergence from upstream, because the Composer name (symfgenus/money-bundle) and repository (hanishsingla/TbbcMoneyBundle) do not match and this is almost certainly a fork needing a VCS repository entry rather than Packagist.
• You have named an internal owner and an exit plan.

Look elsewhere — which is nearly always — when:

• You are on Laravel. Require moneyphp/money directly (the maintained successor to the library this wraps), add an Eloquent cast mapping integer minor units + a CHAR(3) currency column to a Money object, add a NumberFormatter presenter and a currency validation rule. That is roughly a day of work and gives you the same domain capability without a Symfony 2 dependency. There is no scenario where routing a Laravel app through a Symfony 2 bundle is correct.
• You are on Symfony 4/5/6/7 or PHP 8+. This predates autowiring, Flex recipes, and modern bundle conventions. You will spend more effort fighting it than writing the wiring.
• You want the pattern, not a container binding. Go straight to the library; the pattern survives, the adapter does not.
• You need FX conversion, configurable rounding contexts, Doctrine types, or serialization. None of that is here. Evaluate brick/money if first-class currency conversion and configurable context matter.
• Supply-chain or compliance review applies. Zero stars, zero dependents, no release cadence, an abandoned ancestor library, and an EOL framework target are independent red flags a security review will find anyway. Reach the conclusion first.
• You need a decision this quarter. With no maintainer signal and no dependents to observe, you would be the sole consumer and would own the fork outright.

Migration note for the roadmap: depend on the money library directly (or its maintained successor) and treat any Symfony bundle wiring as a small piece of first-party code you control. That drops a dependency, removes an abandoned third party from the critical path, and costs on the order of a day.

How to Pitch It (Stakeholders)

To executives — one paragraph: "This is a thin, unmaintained glue layer that makes a well-regarded money-handling library available in an obsolete framework. The library's core idea is sound and is what we actually want: represent money as an amount plus a currency, never as a floating-point number, so pricing, billing, and reporting cannot drift by a cent. The package itself has zero adoption, zero downstream users, and targets a framework generation we should not be building on — and it is not a Laravel package at all, so it does not fit the stack in question. Recommendation: adopt the pattern, not the package. Approve money-as-a-value-object as an engineering standard, and fund a small piece of first-party wiring rather than inheriting an abandoned dependency."

To engineering leadership — the ask and the risk:

• The asset is the pattern. Integer minor units plus an explicit currency type eliminates a whole class of rounding and currency-mixing defects. That win is independent of this repository and survives any library choice.
• The liability is the wrapper. Zero stars, zero dependents, no maintainer signal, Symfony 2 only, mismatched fork provenance, and an upstream library that has since been superseded by moneyphp/money. There is no community to absorb a bug — we would be the sole owner of any fork.
• The recommendation is a one-day substitution, not an adoption. Depend on the maintained library directly and write the wiring ourselves: an Eloquent money cast, a locale-aware formatter, a currency validation rule, and allocation logic kept in the domain layer with golden-value tests. Net effect: same capability, one fewer unmaintained third party on the critical path.
• Treat this as migration input, not feature input. If we are on Symfony 2 today, its presence on the dependency list is evidence of an EOL platform. Frame the conversation as platform exit planning and let this be a line item there.
• What would change the recommendation: if a legacy Symfony 2 service is genuinely in scope and in freeze mode, the package is defensible as a pinned, snapshotted fork with a named owner and a recorded ADR. If a compliance audit requires showing diligence, that ADR — "we evaluated this and chose the direct dependency, here are the criteria" — is the artifact to file.