Currency Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy evaluation for multi-currency support. This package is evidence for the "don't build it, and don't buy this either" conclusion — it lets you close out a currency-handling spike quickly instead of spending sprint time on an option that has no maintenance runway.
• Reference scoping, not implementation. The feature set a currency bundle typically covers — ISO 4217 code validation, display formatting/locale-aware rendering, and exchange-rate sourcing — is a useful checklist when writing your own requirements, even though the code itself shouldn't ship.
• Legacy audit / acquisition due diligence. If you inherit a Symfony application with this in composer.json, its archived status is a roadmap item: you now own an unmaintained dependency with no upstream security patching, and it needs a scheduled replacement.
• Vendor and dependency risk policy. A concrete test case for whatever rule you set around "no actively maintained upstream = no production dependency," useful for calibrating how strict that policy should be.
• Framework-fit decision. It sharpens the point that a Symfony Bundle is not a Laravel package — bundles assume Symfony's kernel, DI container, and config tree. If multi-currency is on the roadmap, this confirms you need to budget for a Laravel-native solution rather than assuming PHP ecosystem packages are portable.

When to Consider This Package

Consider it only when:

• You are maintaining an existing Symfony application that already depends on it, and you need to understand what it does before replacing it.
• You need a taxonomy of currency-related concerns (codes, formatting, rates) to inform your own spec — read it, don't require it.
• Nothing else: there is no scenario where adding this to a new or actively developed codebase is defensible.

Look elsewhere — default to this — when:

• You are on Laravel. The framework mismatch alone rules it out; there is no supported integration path.
• You need maintained code. Archived means no bug fixes, no security patches, no PHP-version compatibility work, and no response to a CVE in a dependency it pulls in.
• You need community support. Zero stars and zero dependents means no one is running this in production; any issue you hit, you debug alone.
• You need exchange rates, rounding strategies, tax/VAT interaction, or multi-currency price storage. These are the hard parts, and an unmaintained bundle will not have kept pace with them.
• Better alternatives to evaluate instead: moneyphp/money (mature, widely adopted, framework-agnostic) or brick/money, paired with your own rate-provider abstraction and a persisted rate table. In Laravel, wrap either in a thin service provider plus a Blade/formatter helper. These give you the currency semantics without the bundle's assumptions.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. No further evaluation needed.

flagbit/currency-bundle is a Symfony Framework bundle that is formally archived upstream, with zero stars and zero dependent projects. Those three signals together mean: no maintenance, no security patching, no production usage to learn from, and no upstream to escalate to. It is also the wrong framework — a Symfony bundle does not install into a Laravel application, so the integration cost would be a rewrite rather than a wiring task. License (BSD-3-Clause) is permissive and unproblematic, but permissive licensing does not compensate for an abandoned upstream.

For executives: this is a closed question, not a trade-off. Adopting unmaintained code in the payments/pricing path creates a standing security and reliability liability with no vendor to fix it. The cost of ownership exceeds the cost of the ~2–3 days it takes to integrate a maintained library.

For engineering: the underlying problem — currency codes, formatting, conversion, rounding — is real and worth solving deliberately. Use moneyphp/money or brick/money, keep exchange rates behind your own interface and a persisted table so the rate source is swappable, and be explicit about rounding policy before you write pricing logic. Treat this bundle as a requirements checklist only.

If you have it in an existing app: prioritize a replacement ticket. There is no patch path.