Currency Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and the framing mismatch is the headline finding. Despite being indexed as a "Laravel/PHP package," flagbit/currency-bundle is a Symfony FrameworkBundle. Its entry point is a Bundle subclass registered in AppKernel, its configuration flows through a DependencyInjection\Extension + Configuration tree, and its services are wired via compiler passes and XML/YAML service definitions. Laravel has no bundle registry, no Extension/Configuration contract, and no compiler-pass lifecycle. The only overlap is the PSR-11 container boundary, which is not enough to make the package loadable. In a Laravel application this package is effectively inert code: installing it adds a vendor directory and nothing else executes.

Integration feasibility — low, and the cost is a port, not an integration. Making it useful requires translating the bundle into Laravel idioms: Extension → ServiceProvider, config tree → config/currency.php, service definitions → container bindings/singletons, Symfony event subscribers → Laravel listeners. That is not a configuration exercise; it is a rewrite with the original source as a reference spec. The effort is only justified if the underlying domain logic (currency entity, exchange-rate retrieval, conversion arithmetic) is both non-trivial and cleanly separable from Symfony wiring — which cannot be assumed for a bundle of this vintage.

Technical risk — high, concentrated in the dependency graph. Three signals compound:

• Archived: yes — no security response, no PHP-version compatibility work, no upstream fixes. Any CVE in a transitive dependency is permanently ours.
• 0 stars / 0 dependents — no production evidence anywhere. We would be the first adopter of a package nobody has run in anger.
• Scanner score 0.05 — consistent with the above; treat as a non-viable candidate unless discovery overturns it.

The practical failure is likely to arrive early: bundles of this era pin symfony/* to ^2/^3 and PHP to 5.x/7.x, which will hard-conflict with Laravel 10/11 (Symfony 6/7, PHP 8.1+). Expect composer require to fail on resolution, not to succeed and misbehave — a cheaper failure, but a failure.

Key questions for discovery:

1. What capability do we actually need — currency storage and enumeration, exchange-rate retrieval, conversion arithmetic, or display formatting? These decompose differently and only the first two are plausibly bundle-shaped.
2. Read the source: how many services are there, and is the conversion math self-contained or fused to Doctrine/Symfony forms and Twig helpers?
3. Does the bundle call an external FX provider synchronously, and is the provider still operating in 2024+?
4. What is the storage type for rates — float or decimal? Float currency storage is a correctness defect we would inherit.
5. Is there a maintained Symfony-native equivalent, or a framework-agnostic library (moneyphp/money, brick/money) that covers the same ground with an active maintainer?
6. BSD-3-Clause is permissive and low-friction — attribution only. Not a blocker, but confirm attribution is retained in any vendored/derived code.

Verdict: reject for direct adoption. The package fails on stack fit before it fails on maintenance, and it fails on maintenance before it fails on quality. Retain as a reference implementation to be read during discovery, not a dependency.

Integration Approach

Stack fit — none, by construction. Laravel's currency needs are met by framework-agnostic value objects plus a Laravel-native service provider. This package cannot occupy that slot without being rewritten into it. The correct mental model is: we are not integrating a package, we are deciding whether to port one.

Migration path. The only coherent path is an extraction-and-replace:

• Extract the domain. Isolate the conversion and rate-lookup logic from the Symfony wiring. If it is ≤ a few hundred lines of arithmetic and HTTP calls, vendoring it under our own namespace with tests is cheaper than any adapter layer — and removes the archived dependency from composer.json entirely.
• Rebuild the edges in Laravel. ExchangeRateProvider and CurrencyConverter as interfaces bound in a CurrencyServiceProvider; rates behind a cache repository with a scheduled RefreshExchangeRates command; decimal-typed storage.
• Substitute a maintained arithmetic core. moneyphp/money or brick/money for value objects and rounding; our own provider for rates. This is where the real durability comes from — the FX plumbing is commodity, the bundle was never the differentiator.

Compatibility. Assume incompatibility until disproven, and disprove it cheaply before any design work: clone the repo, run composer why-not laravel/framework, and check the composer.json PHP and symfony/* constraints. If the constraints are Symfony 2/3-era, stop — the investigation is over. There is no shim, no polyfill, and no maintained fork.

Sequencing:

1. Discovery (timeboxed, ~1 day). Read source; inventory services; answer the six questions above; confirm the actual business capability required.
2. Build-vs-buy decision. Document the comparison against moneyphp/money + in-house provider. The archived package should have to win this comparison, which it will not on maintenance grounds alone.
3. Interface-first implementation. Define ExchangeRateProvider / CurrencyConverter in our domain before any implementation, so the vendor choice stays reversible.
4. Data migration. If the bundle's schema (currency tables, rate history) exists in a legacy database, model the migration and precision changes explicitly — this is the step most often underestimated.
5. Decommission. Remove the bundle from any legacy Symfony service; do not carry it forward as a bridge.

Where a legacy Symfony estate is involved: if we are migrating from a Symfony app that already runs this bundle, the bundle is a migration liability, not an asset. Port the behavior, do not lift the code. The rewrite cost is paid either way, and paying it once — into a maintained library — is the only version that does not recur at the next PHP upgrade.

Operational Impact

Maintenance — the dominant cost, and it is unbounded. Archived means zero upstream maintenance, transferred entirely to us. Every future PHP minor, every Symfony/Laravel major, every CVE in a transitive dependency becomes our ticket. A fork-and-own arrangement is viable only for a small, stable, dependency-light codebase; a Symfony bundle from this era is unlikely to be any of those. Budget the ongoing cost as we now maintain a currency library, and ask whether that is a capability the team should own.

Support — effectively absent. 0 stars, 0 dependents, archived: there is no issue tracker with activity, no maintainer to escalate to, no community surface to search. Every defect is diagnosed by reading source. For a payments-adjacent capability, that is a poor support posture, and it will surface as extended MTTR during an incident rather than as a line item.

Scaling — the rate-refresh path is the pressure point, not request volume. Currency conversion itself is cheap arithmetic; the scaling risk is external FX provider calls. Requirements regardless of implementation: cache rates with an explicit TTL, refresh on a schedule rather than per-request, rate-limit and retry against the provider with backoff, and hold a durable last-known-good snapshot. If the bundle fetches rates synchronously per request, it will not survive production traffic and will couple checkout latency to a third party's availability. Verify this in discovery — it is the single most likely operational defect.

Failure modes to design against:

• Stale rates — silent and expensive: mispriced carts, incorrect invoices, reconciliation drift. Needs freshness monitoring and an alert threshold on rate age, not just error handling.
• Provider outage — hard-fail versus serve-stale is a product decision that must be made explicitly, per surface (browse vs. checkout).
• Rounding and precision — float storage and ad-hoc rounding produce cent-level drift that compounds across orders and is painful to unwind. Enforce decimal storage and a single rounding policy at the boundary.
• Build breakage on platform upgrade — the most probable near-term failure; a PHP/Laravel upgrade fails at composer update with no upstream fix path.
• Orphaning — with zero dependents and no maintainer, there is no scenario in which the ecosystem repairs this for us.

Ramp-up — deceptive. For an engineer fluent in Symfony, the code is readable in hours; for a Laravel team with no Symfony bundle experience, the wiring is unfamiliar and the payoff is a port. Either way the onboarding cost is "read the source and reverse-engineer intent," with no documentation to anchor against. That cost is paid and then stranded, because the knowledge is specific to code we intend to replace.

Bottom line for planning: treat this as a build-vs-buy input, not an adoption candidate. The scanner score of 0.05 is the correct read. Recommend a one-day discovery to extract any genuinely reusable domain logic, then implement the capability on a maintained, framework-agnostic foundation behind Laravel-native interfaces. The archived bundle has no path to production in a Laravel stack that does not begin with rewriting it.