Money Bundle Laravel Package

Technical Evaluation

What v1.3.0 changes. The release contains exactly one item: added support for Symfony 5.x. There are no new features, no changes to the Money domain surface, no deprecations, no license file, and — critically — no Laravel-relevant work of any kind. This is a compatibility bump that keeps an existing Symfony bundle installable on Symfony 5 applications. It does not introduce new extension points, new container behavior, or new value to a stack that is not Symfony.

Two observations matter more than the changelog line itself. First, the bump is to a framework major that is already past its useful life: Symfony 5.4 has been out of bug-fix support since November 2024 and is in security-only maintenance, so the bundle has been modernized to a version we would not start new work on. Second, the release demonstrates that the maintainer can still resolve a version constraint, but nothing more — there is no bug fix, no security review, no test or CI signal, and no indication of ongoing stewardship. This is a resurrection, not a revival.

Architecture fit. Unchanged and, if anything, reinforced. The package is a Symfony bundle whose entire value is Symfony-specific extension points: a Bundle subclass, a DependencyInjection\Extension with a semantic configuration tree, tagged service definitions for the Money library's services, and likely Twig extensions, Form types, Validator constraints, and Doctrine DBAL types. v1.3.0 makes those surfaces target Symfony 5, which moves the package further from anything Laravel exposes. A Laravel application still cannot install this meaningfully — no bundle registration, no Configuration tree, no tag compiler pass, no cache warmer. What remains transferable is a composer.json pulling in the upstream Money library plus XML/YAML service definitions a Laravel engineer would read and hand-translate. That is a reimplementation, not an integration.

Integration feasibility. Low, still not worth pursuing. The only transferable artifact is the upstream dependency — almost certainly moneyphp/money — a standalone, framework-agnostic library with no Symfony coupling. A Laravel team needing Money support should depend on it directly and write a thin service provider, an Eloquent cast, and a validation rule: roughly one engineer-day producing code you own, understand, and can upgrade. Nothing in v1.3.0 changes that arithmetic.

Technical risk.

Key questions for the maintainer spike (if it proceeds at all).

1. Which version of moneyphp/money does v1.3.0 target, and are the service definitions trivially reproducible?
2. Is there a LICENSE file in the repository, and can the author confirm a standard OSI license in writing? (v1.3.0 does not resolve this.)
3. What is the declared php constraint range in v1.3.0, and is there an upper bound that excludes 8.3/8.4?
4. Does v1.3.0 add any behavior beyond container wiring — money formatting policy, rounding defaults, serialization conventions — that we would inherit implicitly? (Changelog suggests no.)
5. Is there evidence of ongoing maintenance beyond this single commit — CI config, open-issue triage, a stated support policy or Symfony 6/7 roadmap?
6. Is there a maintained Laravel-native alternative in our existing dependency set (casts, brick/money, or in-house value objects) that closes the gap?

The opportunity score (4.78) should still be read as "there is value in the Money domain," not "there is value in this wrapper." v1.3.0 does not change that distinction — it is a Symfony-side maintenance release that scores well on domain relevance and zero on fit.

Integration Approach

Stack fit. Adopt the domain library, reject the bundle — recommendation unchanged by v1.3.0. Target stack: moneyphp/money (MIT, actively maintained, PHP 8.2 compatible) plus Laravel-native glue. The glue surface is small and well-bounded:

• A MoneyServiceProvider binding a currency resolver and a money factory to the container.
• An AsMoney Eloquent cast mapping a value object to two persisted columns (amount_minor BIGINT, currency CHAR(3)) that fails loudly on currency mismatch.
• A MoneyRule validation rule accepting { "amount": "1234", "currency": "USD" } payloads in integer minor units.
• An API resource / serializer transform emitting minor units plus ISO 4217 code — never floats, never locale-formatted strings — at the boundary.
• A Blade directive or helper for display-time formatting only, with locale and rounding kept out of persistence.

Migration path. Nothing to migrate from unless a Symfony service is being ported — and if it is, note that v1.3.0 targets Symfony 5, so any porting work should assume Symfony 5 idioms, not the 2020-era Symfony 4 configuration the original assessment described. Inventory the bundle's service configuration, map each service to a Laravel container binding, and delete the Symfony-specific decorators (Twig/Form/Validator) in favor of Laravel equivalents. If the package is already pinned in a legacy composer.json, removing it is the migration — verify no application code references bundle namespaces before deletion.

Compatibility. Pin moneyphp/money to a specific major (v4.x) and record the decision. Verify PHP 8.2/8.3 and the current Laravel LTS in CI. Keep the bundle out of the dependency graph even transitively — a NOASSERTION license in the tree is a procurement finding at audit time, and an unresolvable or upper-bounded PHP constraint surfaces six months later as a confusing Composer conflict. If the v1.3.0 PHP range turns out to admit 8.3+, that removes one objection but does not touch the blocking framework mismatch or the license.

Sequencing. (1) One-day spike confirming v1.3.0 adds no behavior we cannot reproduce, recording its php and Symfony constraints and its license status as a formal rejection rationale. (2) Approve moneyphp/money through standard dependency review. (3) Build and test the cast, rule, and serializer against a single reference entity. (4) Ratify the persistence convention (integer minor units + currency column) as an architecture decision record. (5) Roll out to remaining entities; add static analysis to block float-typed money fields.

Operational Impact

Maintenance. The bundle is low-activity, and v1.3.0 is a single compatibility commit — it does not establish a cadence. Adopting it means owning a fork of code you did not write, in a framework you do not run, targeted at a Symfony major already in security-only support, to solve a problem upstream already solves. That last point is now sharper: adopting v1.3.0 starts you on an upgrade clock you did not choose. The upstream library, by contrast, has an active release cadence and a real user base. Ownership cost for the Laravel glue stays low: roughly 200–300 lines of well-tested code with a stable interface.

Support. Still no maintainer response path. Twenty-two stars and zero dependents means no community to fall back on and no evidence anyone has run this in production at scale. A six-year-latent constraint bump is not a support commitment. Escalation for a defect remains "read the XML and figure it out," which is the same work as writing the glue — but paid later, under incident pressure.

Scaling. Negligible runtime footprint either way — money conversion is CPU-trivial and stateless. The scaling concern is organizational: without a ratified persistence convention, teams independently invent representations (floats in one table, strings in another, formatted strings in a third), and reconciliation cost grows with the number of services rather than request volume.

Failure modes to design against.

• Float leakage — any path storing or transporting money as a float introduces silent precision loss; enforce integer minor units at the cast and serializer boundary.
• Currency mismatch — combining value objects of different currencies must throw, not coerce; the single most common production defect in money handling.
• Serialization drift — an API emitting formatted strings ties the contract to locale and breaks consumers on format changes; emit minor units + code.
• Rounding policy ambiguity — allocation and division need an explicit, documented rounding mode; leaving the default implicit produces off-by-one-cent discrepancies in financial reports.
• Schema mismatch — DECIMAL with insufficient precision or a non-ISO currency column passes tests and fails at scale.
• Silent dependency substitution — if the bundle is later removed from a legacy app, confirm no code imports its namespaces, or you get class-not-found errors in untested paths.
• Faux-maintenance trap (new) — a single "added support for X" release can look like revived stewardship in a dependency review. Score maintenance on cadence, issue triage, and test coverage, not on one commit.

Ramp-up. Under a day for any engineer familiar with Laravel to use the glue; the real ramp-up is domain discipline — minor units, ISO 4217, and where formatting belongs. Budget a short written standard alongside the code so the convention survives team turnover.

Verdict. Do not adopt kucharovic/money-bundle. v1.3.0 warrants a review note but not a change of recommendation: the framework mismatch remains disqualifying on its own, the license remains unresolved, and the headline feature is support for a Symfony major already past its bug-fix window. The release corrects one fact in the prior assessment — the package is not untouched since 2020 — without supplying any evidence of sustainable maintenance. Take the upstream Money library, write the thin Laravel glue, and record the rejection — with v1.3.0 cited — so it is not re-evaluated next quarter on the strength of a version bump.