Money Formatter Laravel Package

Technical Evaluation

Architecture fit

• Thin, single-purpose Laravel wrapper: a service provider, facade, config file, and a formatter class that almost certainly delegates to moneyphp/money plus number_format/symbol lookup. It is a convenience layer, not infrastructure.
• Fits the Laravel idiom of 2014–2015 (package discovery not yet standard, manual provider registration, config publish). It does not represent architectural leverage; the entire surface area is likely under a few hundred LOC and can be reproduced in-house in a day or two.
• No domain modeling contribution: rounding policy, currency exponent handling, and locale-aware output are exactly where money bugs live, and a 9-star package from 2015 with zero dependents gives no evidence those are solved.

Integration feasibility

• Last release 2015-03-26 implies constraints against illuminate/support 4.x/5.0 and PHP 5.4–5.6. Installation on a current Laravel (9/10/11) or PHP 8.x stack will fail dependency resolution; forcing it with --ignore-platform-reqs only defers a runtime failure.
• The package predates Laravel auto-discovery and composer.json extra.laravel conventions; expect manual provider/facade wiring and config publishing even on a compatible framework.
• No test suite, CI badge, static analysis, or security policy is evident. Nothing verifies behavior on any PHP version, so "it works" would be an assumption, not a finding.

Technical risk

• High. Abandoned for ~10 years, single maintainer, 9 stars, 0 dependents, package score 0.105 — this is the bottom of the distribution on every signal except license (MIT, which is the only favorable attribute).
• Supply-chain surface is small but unmonitored: no CVE feed, no release cadence, no maintainer responsiveness. Unmaintained formatters are not typically exploited, but they silently block framework and PHP upgrades, which is the real cost.
• Correctness risk is the dominant one: money formatting failures are silent (wrong symbol placement, wrong decimal count on zero-decimal currencies like JPY/KRW, banker's vs. half-up rounding, negative-number rendering) and surface in invoices, receipts, and financial exports.

Key questions

• Does it depend on moneyphp/money, and at which major version? That determines whether the underlying value object is salvageable.
• Is output locale-aware via ext-intl/ICU, or hardcoded number_format with a config symbol map? The latter is not a formatter, it's string concatenation.
• How are currency exponents, rounding modes, and negative/zero amounts handled, and is any of it covered by tests?
• Is the formatting contract exposed behind an interface, or is the facade called statically throughout consuming code?
• Does a maintained fork or successor exist, and is nwidart/laravel-modules (the maintainer's active project) an indicator this one is intentionally retired?
• What is our actual requirement — display formatting only, or parse/convert/allocate money too?

Integration Approach

Stack fit

• Compatible only with a legacy Laravel 4.2/5.0 estate on PHP 5.x. On any modern stack it is a non-starter; the correct reading of this package is "reference implementation," not "dependency."
• If the estate is already legacy, the package still adds an unpatched dependency that will block the eventual framework upgrade — the opposite of what a TPM should approve ahead of a migration.

Migration path

• Do not migrate to this package. If it is already present, migrate off it.
• Target: moneyphp/money 4.x for the value object and arithmetic, with ext-intl's NumberFormatter for locale-aware output — or brick/money if allocation and multi-currency arithmetic are in scope. Both are actively maintained with real test suites.
• Preserve the package's public surface as an application-level adapter (App\Support\MoneyFormatter implementing a MoneyFormatterInterface) so the 2015 API maps 1:1 onto the replacement and call sites do not change.
• If the app cannot take ext-intl, fall back to a small explicit symbol/decimal table with unit tests per currency — but make that an explicit, owned decision rather than inheriting it from an abandoned package.

Compatibility

• Expect conflicts with modern illuminate/*, nesbot/carbon, and moneyphp/money version pins. Check composer why before and after removal to confirm nothing else transitively depends on it.
• Verify PHP 8.1+ deprecation behavior (dynamic properties, optional-before-required parameters) if any code path survives.

Sequencing

1. Inventory: grep for facade/class usages and config keys; quantify call sites and output surfaces (API responses, PDFs, emails).
2. Define the formatting contract: currencies in scope, locales, decimal/symbol placement, rounding mode, negative and zero rendering, and the expected string for each. This is the actual deliverable.
3. Spike moneyphp/money + intl against that contract in a branch; write characterization tests from the current output to detect regressions.
4. Build the adapter behind the interface; swap the binding; keep the old formatter available behind a flag for one release.
5. Remove the package and its config; add a lint/CI rule preventing reintroduction.
6. Total effort: roughly 1–3 developer days for a typical app, dominated by step 2 — not by code.

Operational Impact

Maintenance

• Zero upstream maintenance. No releases since 2015, no PHP 8 fixes, no dependency bumps, no security advisories. Every future framework upgrade becomes a manual patch of a package we do not own.
• Owning a fork is possible (MIT, tiny codebase) but means we inherit the correctness questions in the Technical Evaluation with no test suite to start from.

Support

• Community support is effectively nonexistent: 9 stars and 0 dependents means no Stack Overflow corpus, no issue history to mine, no third-party tutorials. Any incident is debugged from source.
• No vendor, no SLA. Internal knowledge will concentrate in whoever did the integration, which is a bus-factor risk disproportionate to the package's importance.

Scaling

• Runtime scaling is a non-issue: formatting is CPU-trivial and memoizable. It will not be a throughput bottleneck at any realistic volume.
• The scaling concern is coverage: the number of distinct currency/locale combinations grows with market expansion, and a hardcoded symbol map does not scale into new locales. Expect correctness debt proportional to geographic reach.

Failure modes

• Silent misformatting — wrong minor-unit count for zero-decimal currencies, wrong rounding on totals, symbol/placement errors in non-US locales. Detected by customers or finance, not by monitoring.
• Upgrade deadlock — the package's stale constraints block a Laravel/PHP upgrade, forcing an emergency replacement under deadline rather than a planned one.
• Runtime fatal on PHP upgrade — removed/deprecated language features in 2015-era code.
• Inconsistent output — if some code paths use the facade and others use number_format directly, the same amount renders differently across invoices, emails, and API payloads.
• Mitigation for all four is the same: an owned adapter with characterization tests and a single choke point for formatting.

Ramp-up

• Learning the API is hours, not days — it is a formatter facade. The trap is that low ramp-up reads as low risk; the actual risk is concentrated in undocumented edge-case behavior that no one on the team can attest to.
• Budget the real onboarding time for the replacement: moneyphp/money semantics (immutable value objects, minor units, explicit rounding) take a developer 1–2 days to use correctly, and that knowledge is durable and transferable in a way this package's is not.

Recommendation: Do not adopt. Treat as a reference for API shape only. Where already present, replace with moneyphp/money + ext-intl behind an internal interface within one release cycle; the cost is days, and it removes an upgrade blocker and an unmonitored correctness risk simultaneously.