Money Bundle Laravel Package

Technical Evaluation

Architecture fit. syno/money-bundle is a Symfony bundle, not a Laravel package. Its scope is narrow: register moneyphp/money services and configuration inside Symfony's DI container. The substantive value lives in moneyphp/money (Fowler Money pattern), which is mature, widely used, and actively maintained; the bundle is thin glue around it. Laravel has no bundle/kernel-extension mechanism, so the package as shipped cannot be dropped into a Laravel application. What is reusable is the idea of that glue — config keys for default currency, subunit precision, and rounding mode, plus a factory/formatter binding — which is roughly a 100-line service provider we would write and own.

Integration feasibility. Low technical effort, high ownership transfer. Porting the bundle's configuration and bindings into a Laravel service provider is a bounded task. The real feasibility question is version drift: last release 2022-03-28, zero stars, zero dependents. Its composer.json constraints must be verified against the PHP and framework versions in use — a bundle from that era is likely pinned to Symfony 4/5-era APIs and PHP ≤8.0, which conflicts with current Laravel and PHP 8.2+.

Technical risk.

• Abandonment/staleness: single low-traffic repo, no recent releases, no visible issue triage, no security advisories.
• Zero adoption: no downstream users means no field-tested edge cases, no community patches, no searchable corpus of prior failures. We would be the only consumer.
• Bus factor: one maintainer/org; the repo could be archived without notice.
• Supply chain: an unmaintained node in the composer graph is a standing upgrade blocker and an audit finding.
• Correctness risk is not in the bundle — it is in how the team uses Money (floats, mixed currencies, double rounding, remainder allocation). The bundle offers no guardrails here.
• Mitigating factor: MIT license, thin surface, healthy underlying library — so the cost of walking away later is small, which argues for walking away now.

Key questions.

• What does the bundle provide beyond moneyphp/money: only DI/config, or also form types, Twig helpers, serializer normalizers, validators?
• What are its php and symfony/* constraints, and does it install cleanly on the current stack?
• Is the repository archived or explicitly unmaintained? Is any support window stated?
• Who owns it internally if adopted, and what is the documented exit plan?
• Does it pin a moneyphp/money version we would otherwise want to upgrade independently?
• Are currency/rounding defaults baked into the bundle that would silently become business rules?
• Which calculator backend does it assume (bcmath, gmp, or pure PHP), and is that present in every environment?

Integration Approach

Stack fit. Do not install the Symfony bundle in a Laravel application. Adopt moneyphp/money directly as a first-class composer dependency and reproduce the bundle's small amount of glue as an application-level service provider. This keeps us on a maintained library, removes a dead dependency, and preserves the only real benefit — container-managed configuration.

Migration path. With effectively no dependents, assume greenfield:

1. Add moneyphp/money to composer.json, pinned to a known-good minor.
2. Create config/money.php for default currency, subunit precision, and default rounding mode — the settings the bundle would have exposed.
3. Bind a MoneyFactory/CurrencyRegistry singleton in a MoneyServiceProvider; inject rather than new-ing Money inside controllers.
4. If any in-house or bundle-derived integration exists, replace its container IDs with explicit app()->bind() calls and remove the bundle from the graph.
5. Record the decision as a short ADR with the bundle cited as reference material.

Compatibility. Pin php and framework constraints explicitly; run the full test suite against the chosen moneyphp/money version before merging. Check transitive conflicts (serializer, intl) and confirm the calculator backend (bcmath/gmp) exists in CI and production images, not just locally. Persist amounts as integer minor units with an ISO 4217 code column — never FLOAT/DOUBLE.

Sequencing.

1. Spike (½–1 day): read the bundle source to harvest config semantics and decide adopt-vs-reimplement. Expected outcome: reimplement.
2. Domain layer: introduce Money value objects at boundaries only (pricing, invoicing, payments, reporting); define the persistence contract.
3. Boundary conversions: API resources, form requests, and Blade/JSON output routed through a single formatter; ban raw float arithmetic on money paths via review or static analysis.
4. Serialization contract: fix the wire format (e.g. {"amount":"1234","currency":"EUR"}) before any client depends on it.
5. Test strategy: rounding, allocation/split, and currency-mismatch cases; mismatches surfaced as 4xx, not 500s.
6. Decommission: if the bundle is present anywhere, remove it in the same PR that lands the replacement.

Operational Impact

Maintenance. Adopting the bundle means adopting a fork in all but name: no upstream fixes, no PHP 8.3/8.4 readiness, no Symfony 7 support. The wrapper changes rarely, so steady-state effort is low — but it will block framework and language upgrades eventually, and the remediation will be "remove it." Removing it up front is strictly cheaper. An in-house ~100-line provider has a bounded, well-understood maintenance load and no external schedule.

Support. No vendor, no SLA, no documented support channel, no meaningful issue history to search. Internal engineering owns every question, including "why is this total off by one cent." Support should instead come from the underlying library, which has documentation, an active tracker, and broad production usage.

Scaling. Runtime scaling is a non-issue: Money is a lightweight immutable value object and the bundle adds only container wiring. Scale risk is organizational and correctness-based — as more teams and services touch monetary data, inconsistent rounding modes, mixed-currency arithmetic, and float leakage compound. Centralizing configuration and formatting in one provider is the scaling lever; the package is not.

Failure modes.

• Upgrade deadlock: stale version constraints pin PHP/framework, stalling security patching.
• Silent divergence: bundle defaults (currency, precision, rounding) become undocumented de facto business rules.
• Container breakage: Symfony extension/config APIs shift across majors; a stale bundle throws at boot after an upgrade.
• Correctness drift: floats reintroduced at a boundary; rounding applied twice (domain and presentation); remainder allocation producing non-reconciling totals.
• Serialization loss: amounts emitted as floats or with locale decimal separators, breaking clients.
• Missing calculator backend: environments without bcmath/gmp fail or fall back unpredictably at runtime.

Ramp-up. Conceptually low — Fowler's Money pattern is well understood and the library API is small; a mid-level engineer is productive in half a day. The bundle adds no learning value: thin docs, implicit conventions. The real ramp-up cost is documenting our conventions (where Money lives, how it is stored, how it is formatted, what is forbidden), which is required regardless. Budget one short ADR plus a review or lint rule against float arithmetic.

Overall. The score of 0 with 23.59 opportunity reflects reality: an abandoned, zero-adoption wrapper around a good library. Leverage it as design reference, not as a dependency. Recommendation: decline adoption, harvest its configuration semantics, and standardize on moneyphp/money with a small in-house Laravel binding.