Currency Bundle Laravel Package

Technical Evaluation

Architecture fit. Despite the "Laravel/PHP package" framing, elcodi/currency-bundle is a Symfony Bundle, not a framework-agnostic library. Its runtime contract depends on Symfony's DependencyInjection component (Extension, Configuration, service YAML/XML definitions), the Symfony EventDispatcher, and the Elcodi core abstractions it extends. In a Laravel application none of those integration seams exist: there is no Bundle registration, no services.yml loading, no Symfony dispatcher to bind to. The genuinely portable portion is narrow — currency code/value objects, formatting/rounding helpers, and a repository interface — perhaps 20–30% of the package. The rest is Symfony plumbing that Laravel will not consume.

Integration feasibility. Feasible only as an extraction, not an installation. composer require elcodi/currency-bundle into a Laravel project would drag in Elcodi core components and Symfony packages, produce container/event-dispatcher conflicts, and leave you with services you must manually boot. There is no Laravel service provider, no facade, no config publishing. A realistic path is to copy the currency domain classes into app/Support/Currency (or a first-party package), replace Symfony events with Laravel events, replace Bundle configuration with a config/currency.php, and write binding in an AppServiceProvider.

Technical risk (high).

• EOL/archived, read-only since 2016. The README explicitly refuses PRs and redirects to the monorepo, which is itself EOL. There will be no security patches, no PHP 8.x fixes, no dependency updates.
• PHP version drift. 2016-era Elcodi targets PHP 5.6/7.0. Ten years of language and dependency churn (typed properties, deprecations, Symfony 5/6/7 removals) means the code likely will not install cleanly or will emit deprecations across a modern Laravel 10/11 codebase.
• Zero dependents. No downstream projects to validate behaviour against, no community issue history to mine, no forks with fixes. Effectively single-source with no support network.
• Low maturity signal. Maturity is scored at "readme," the composite score is 2.34, and the opportunity signal (0.68) indicates little latent value worth capturing — the domain is commodity logic, not differentiated IP.

Key questions for the business.

1. What problem are we solving — currency formatting/rounding or multi-currency pricing and FX? If it is FX, this package does not do it and never did; if it is formatting, moneyphp/money + brick/money or Laravel's own formatting covers it with active maintenance.
2. Who owns the fork? Any adoption implies indefinite in-house stewardship of abandoned code.
3. Are there compliance or locale requirements (ISO 4217, minor-unit rounding, currency display rules) that a maintained library handles better?
4. Is there any existing coupling to Elcodi elsewhere in the stack? If not, this is a green-field decision and there is no reason to choose archived code.

Integration Approach

Stack fit. Poor as a package; moderate as a reference implementation. Laravel's idioms (service container bindings, config/*.php, Eloquent or plain repositories, Illuminate\Events) have direct equivalents for every Elcodi concept, but the translation must be hand-written. There is no shim, bridge, or community adapter.

Migration path. Recommend do not adopt the bundle. Two viable alternatives, in order of preference:

1. Replace with a maintained library. moneyphp/money (with brick/money for allocation/rounding, and a Laravel formatting layer) is actively maintained, PHP 8+ compatible, framework-agnostic, and has a large dependent base. Wrap it behind a small CurrencyService interface so the choice is reversible. This is the lowest-risk option and delivers equivalent or better functionality.
2. Selective extraction. If internal logic must match legacy Elcodi behaviour exactly (e.g., parity with an existing storefront), vendor the currency entity, formatter, and repository from the archived source into a first-party namespace, strip Symfony imports, add PHP 8 type declarations, and cover with unit tests. License is MIT, so this is legally clean; it is operationally expensive.

Compatibility. Verify PHP constraints before anything else: inspect composer.json for php and symfony/* requirements. Expect to pin or patch. Do not attempt to run the Bundle inside Laravel's container — the abstractions do not map and the debugging cost is unbounded.

Sequencing.

1. Discovery (1 week): read the source, inventory currency classes, quantify what is actually reusable, confirm no Elcodi coupling elsewhere.
2. Decision gate: adopt maintained alternative vs. extract. Bias hard toward replacement; extraction only with a documented parity requirement.
3. Proof of concept (1–2 weeks): implement the currency interface in a branch, run against real pricing/checkout fixtures, compare formatted output and rounding to the legacy behaviour.
4. Parity tests & cut-over: golden-file tests for every supported currency and locale; feature-flag rollout; keep the old path behind a toggle for one release cycle.
5. Decommission: delete any vendored archived code once parity is proven.

Operational Impact

Maintenance. This is the dominant cost. Adopting archived code transfers maintenance to us permanently: dependency bumps, PHP upgrades, security reviews, and bug fixes all become internal work with no upstream to lean on. Budget an ongoing owner, not a one-off integration. The alternative (maintained library) shifts that cost to a vendor/community and is the reason I recommend against adoption.

Support. None from upstream — the README explicitly declines PRs and points to a defunct monorepo. Community channels (Gitter, Twitter, docs site) are dormant and the documentation URL is almost certainly dead. Internal engineers become the sole source of truth; onboarding depends on whoever performed the extraction.

Scaling. Currency formatting and lookup are trivially cheap — stateless, cacheable, not a throughput concern. The scaling question only becomes real if you add FX conversion, which this package does not provide; that would require an exchange-rate provider, caching, and rate-staleness handling, all of which is new build, not inherited value. Plan to cache formatted output per (amount, currency, locale) if used on hot render paths.

Failure modes.

• Silent formatting drift — locale and minor-unit handling in 2016-era code will not reflect current CLDR/ISO 4217 data (new currencies, redenominations, changed symbols). Wrong prices shown to customers is a revenue and trust risk.
• Rounding errors in allocation/tax calculations, hard to detect without golden-file tests.
• Install-time breakage from PHP/Symfony constraint conflicts blocking unrelated upgrades — a latent upgrade tax on the whole application.
• Abandonment risk already realized: no one to escalate to when a bug surfaces under a new PHP version.
• Knowledge concentration — one engineer understands the vendored fork; departure becomes a continuity risk.

Ramp-up. Domain ramp-up is low: currencies, symbols, and rounding are well-understood and the mental model transfers in days. Framework ramp-up is the trap — engineers must learn Elcodi's Symfony-era conventions (Bundle extensions, compiler passes, event subscribers) purely to read and then delete the code. That is pure overhead with no reusable payoff. Mitigate by extracting into idiomatic Laravel services early and never letting the Symfony scaffolding into app/.