Money Laravel Package

Technical Evaluation

Bottom line: This is not a dependency to adopt. It is an archived 2013 library whose own author states it was never intended for production and redirects users to moneyphp/money. A TPM's leverage here is not integration — it is using the package as a design reference and a governance example, and steering the team to the maintained successor. The 7.11 composite score and 15.5 "opportunity" score are artifacts of the scoring model, not evidence of viability; Dependents: 0 and Archived: yes are the decisive signals.

Architecture fit

• Conceptually correct: a Money value object holding an integer amount in a currency's smallest unit plus a Currency is exactly the right domain primitive for a Laravel application (orders, invoices, wallets, payouts, tax lines). Immutability, self-validation, and currency pairing are the properties you want.
• Structurally wrong for a modern Laravel codebase: PHP 5.3-era source (no scalar/return types, no strict types), a hard-coded ISO 4217 currency table frozen in 2013, and an IntlFormatter that pulls ext-intl into any formatting path.
• It is a leaf library with essentially no framework coupling — no service provider, no config, no facade. That means low architectural blast radius if it were used, but also no Laravel-idiomatic ergonomics (no casts, no validation rules, no Eloquent conventions).
• The API is deliberately minimal (construction, amount accessors, arithmetic, comparison). Anything beyond that — allocation/splitting, parsing, formatting, currency conversion — is either absent or you build it.

Integration feasibility

• Mechanically installable: composer require sebastian/money:^1.6 will resolve on most PHP 7.x runtimes. On PHP 8.1+ it is untested and unsupported; expect friction from deprecated behaviors, and treat any green test run as luck rather than a guarantee.
• The real blocker is licensing and provenance: GitHub reports NOASSERTION, so the license must be confirmed from the repository headers before any legal review can clear it. In most enterprises an unclassified license plus an "abandoned" banner ends the evaluation.
• The author's explicit disclaimer ("Please have a look at moneyphp/money instead") is a supportability fact you cannot engineer around. Adopting it means owning every line of it forever.
• Integration cost is low in hours and high in organizational risk: a single sprint to wire up, plus an indefinite tail of "who fixes this when it breaks under a PHP upgrade."

Technical risk

• Correctness risk (highest). Currency metadata is 2013-vintage: missing currencies, stale minor-unit exponents, and no support for later redenominations. For a payments or accounting domain this is a defect class, not a cosmetic gap.
• Precision leakage. Amounts are integers — good — but getConvertedAmount() returns a float, which invites float arithmetic back into the codebase at exactly the boundary you adopted the library to protect.
• Platform risk. No PHP 8 support commitment, no CI signal, no security response path. Any future Laravel upgrade makes this a known-broken dependency to be excused or removed.
• Bus factor / supply chain. Archived repository, zero dependents, no maintainer. An unmaintained package in a financial path is an audit finding in regulated environments.
• Reputational risk. Choosing a library whose readme says "abandoned" and "not for production" is difficult to defend in a design review six months later.

Key questions to resolve before any code is written

1. Who requested this, and what problem are they actually solving — float rounding, currency-aware validation, or multi-currency support?
2. Is there a regulatory, audit, or accounting-control requirement that mandates a maintained, license-cleared dependency in money-handling code paths?
3. What PHP versions must we support across the next 24 months, and does the target runtime already exceed this package's tested range?
4. Has legal/OSS review seen NOASSERTION? What is the policy for unclassified licenses?
5. If we adopt moneyphp/money instead, is the team's objection about API familiarity, bundle size, or something substantive we can address directly?
6. Do we need capabilities this package never had (allocation of remainders, parsing localized input, exchange rates)? If yes, the gap is the requirement, not the library.

Integration Approach

Stack fit

• Poor as a runtime dependency on Laravel 10/11 (PHP 8.1+). Acceptable as a reference implementation: read the source to derive your own value-object conventions, exception taxonomy, and test cases, then implement against moneyphp/money.
• moneyphp/money is the intended successor, is actively maintained, is the de facto standard across the PHP ecosystem, and covers the same value-object contract plus allocation, parsing, and formatting. It is the only defensible choice for production.
• If governance insists on a house abstraction, wrap the money library behind a thin application-level interface (e.g., App\Support\Money\MoneyFactory and an Eloquent cast) so the underlying package is swappable and testability is preserved.

Migration path

• For greenfield work: do not install sebastian/money at all. Go straight to moneyphp/money, pinned, with ext-bcmath/ext-gmp available and Composer audit enabled.
• For any existing code already touching this package: treat it as a rewrite, not an upgrade. Map the ~5 real API surfaces (new Money(int, Currency), getAmount, getConvertedAmount, add/subtract, equals) onto the successor; the shapes are close enough that a mechanical port is feasible per call site.
• Establish a hard boundary in the domain: no floats in money code, integers plus currency code everywhere, and formatting only at the presentation edge.
• Add static-analysis rules (PHPStan/Psalm custom rule or a PHP_CodeSniffer sniff) that ban float in money-typed signatures and ban direct construction outside the factory. This is the durable safeguard; the library choice is secondary.

Compatibility

• Verify PHP runtime matrix, ext-intl availability in the container image, and BCMath/GMP presence before committing. Formatting and arithmetic extensions are the usual surprise in CI versus local.
• Confirm database column types: store minor units as BIGINT with an explicit currency column; never FLOAT/DOUBLE. This matters more than the library and survives any future swap.
• Confirm license classification of both this package and its replacement against OSS policy before the procurement conversation, not after.

Sequencing

1. Discovery (½–1 day): Confirm the business requirement and record the decision to reject sebastian/money with the readme disclaimer and archive status as cited rationale. This is the deliverable.
2. Evaluation spike (1–2 days): Prototype the same three real use cases (order total, tax split, refund) against moneyphp/money; capture rounding-mode behavior and allocation semantics in tests.
3. Architecture decision record (same week): Publish the ADR — chosen library, integer-minor-unit storage, formatting boundary, static-analysis guard. Route for legal/security sign-off.
4. Foundation (1 sprint): Add the dependency, the Eloquent cast, the factory, and the lint rule; land the guardrails before feature work so no one reaches for float.
5. Remediation (parallel, prioritized): Port any legacy call sites touched by this package, ordered by financial exposure — checkout and ledger paths first, reporting last.
6. Closure: Remove sebastian/money from composer.json, confirm composer why returns nothing, and note the replacement in the dependency inventory.

Operational Impact

Maintenance

• Zero upstream maintenance. No releases since November 2013, repository archived, no issue triage, no security advisories, no compatibility work. Every future PHP, ICU, or ISO 4217 change becomes your ticket.
• Internal maintenance burden is "own the fork": even a trivial fix requires vendoring or a Composer patch, which is a standing tax and a code-review debate each time.
• The 2013 currency table is the nastiest ongoing item: minor-unit exponents and currency membership drift, and correcting them means forking a dead library.

Support

• No vendor, no maintainers, no community to escalate to. Stack Overflow answers and blog posts will reference APIs and PHP versions that no longer match your runtime, so troubleshooting cost lands entirely on the team.
• Onboarding cost is disguised: the code looks trivially simple, so a new engineer will assume it works and only discover the staleness at the worst moment — during a currency or PHP upgrade.
• Incident response is undefined. If a rounding bug appears in production, there is no upstream fix to pull; it is an internal engineering effort with financial reconciliation exposure.

Scaling

• Throughput is a non-issue: these are small immutable objects with integer arithmetic; CPU and memory are negligible at any realistic Laravel volume. Do not let performance enter the decision.
• The real scaling axis is correctness under volume and variety: more currencies, more locales, more edge denominations (zero-decimal like JPY, three-decimal like KWD, redenominated currencies). This is precisely where the frozen metadata fails.
• Horizontal scaling of the app is unaffected; the risk concentrates in data integrity — a single wrong minor-unit assumption corrupts ledgers that then require manual reconciliation across systems.

Failure modes to design against

• Silent precision loss: a getConvertedAmount() float value re-entering arithmetic, producing sub-cent drift that only surfaces at reconciliation.
• Currency mismatch: operating on two Money instances of different currencies; ensure the exception path exists and is tested, and that it is caught at the domain boundary rather than in a controller.
• Metadata drift: an unsupported or mis-exponented currency causing an order of magnitude error (100× or 1000×) with no exception raised.
• Runtime break: a PHP upgrade fatals on unmaintained 2013 source, discovered late in a release cycle.
• Governance failure: the dependency ships without confirmed license classification and is flagged in the next audit.

Ramp-up

• Developer ramp-up on the concept is fast — one to two hours for a mid-level engineer to be productive with a Money value object, and the design is genuinely instructive for teaching value objects and immutability.
• Ramp-up on the decision is the expensive part: expect a design review, an OSS/legal consultation, and a written rationale for rejecting a popular-looking package. Budget that stakeholder time explicitly, because "it looks simple and has 726 stars" will be raised again in six months.
• Use the readme disclaimer as the primary artifact: it converts the conversation from a technical debate into a documented, author-endorsed rejection, and it makes the successor library an obvious choice rather than a preference.