Currencies Laravel Package

Technical Evaluation

Architecture fit mibo/currencies is a reference-data library: it maps ISO-4217 currency codes to metadata (numeric code, minor unit/exponent, potentially name/symbol). Architecturally this is a leaf dependency — no framework coupling, no I/O, no persistence, no service provider expected. That is the safest possible position in the dependency graph, since it cannot constrain domain or persistence design. However, the architecture fit question is not "does it fit" but "does it earn a slot": its scope overlaps almost entirely with symfony/intl (already a transitive dependency of laravel/framework in most installations) and with moneyphp/money / brick/money, which ship currency data alongside arithmetic. Adopting it introduces a second, potentially divergent source of truth for currency metadata unless an adapter boundary is enforced.

Integration feasibility Presumed PSR-4 autoloaded Composer package with static or simple instance accessors. Consumption from Laravel is trivial: bind a CurrencyRepository interface in a service provider and delegate to the package. Integration effort is hours, not days. The absence of framework integration (config publishing, validation rules, Blade directives) is not a defect — it is the correct scope for a data package — but it means the package delivers raw data only; any Laravel-idiomatic ergonomics are yours to build.

Technical risk Risk is high relative to the value delivered, for concrete reasons:

The severity is not abandonment per se — it is silent incorrectness. ISO-4217 changes a handful of times per year: new codes (ZWG), redenominations (HRK→EUR), minor-unit/exponent revisions, fund and precious-metal code adjustments. A stale table yields a wrong decimal exponent, which produces 100× display and rounding errors in invoices, tax calculations, and payment payloads without throwing an exception. That is the worst failure class: no error log, no alert, just wrong money.

Equally, adoption implies a supply-chain decision: a small, unaudited, zero-coverage package is the standard attack vector for Composer-based incidents.

Key questions

1. Is the dataset verified against the current ISO-4217 list, including the last 24 months of amendments and historical/withdrawn codes?
2. Does it expose minor units (exponents) and numeric codes, or only alphabetic codes? Exponent support is the deciding capability.
3. What is the update process and cadence, and is there a changelog tied to ISO revisions?
4. Is there a test suite and CI? Are there tests asserting specific, recently-changed codes?
5. Semver discipline and release history — is ^1.0 meaningful or is dev-main the only usable ref?
6. Runtime dependencies, PHP version floor, and conflicts with symfony/intl or moneyphp/money?
7. Does it include symbols, localization, or formatting — or purely ISO reference data?

Integration Approach

Stack fit Anticipated to work on PHP 8.x within Laravel 9–12, with no framework-imposed constraints. Verify Composer constraints explicitly rather than assuming; a stale PHP floor or an unpinned dependency is a common blocker for an unmaintained package.

Migration path Adoption risk is low if the boundary is set at adoption time and not retrofitted. The real migration hazard is developers calling the package's static API (Mibo\Currencies\Currency::find(...)) directly across controllers, models, and jobs. Mandate an internal interface from day one:

App\Support\Money\CurrencyRepository  (interface)
  └── MiboCurrencyRepository          (thin adapter)

Swapping to symfony/intl, a vendored table, or moneyphp/money later becomes a one-class change plus a container binding. Because the package is pure data, there is no data migration, no schema change, and no backfill — the swap cost is genuinely low if and only if the adapter exists.

Compatibility Confirm two things: (a) the package does not conflict with symfony/intl's Currencies class or moneyphp/money's currency list at the Composer or namespace level; (b) if both are present, decide which is authoritative for minor units. Two sources of truth for exponents is a defect waiting to surface.

Sequencing

1. Data audit first — diff the package's table against the authoritative ISO-4217 list and the symfony/intl data already in the lockfile. If the diff is empty or trivial, the package adds nothing.
2. Spike in a branch — install, wrap, and assert against known-tricky cases (JPY exponent 0, KWD/BHD exponent 3, CLP exponent 0, ZWG, withdrawn codes).
3. Decide build-vs-adopt — a vendored, tested copy of the ISO table is ~200 lines and eliminates abandonment risk entirely.
4. If adopted: pin an exact version (not a floating constraint), add a regression test asserting expected currency count and a handful of specific exponents, and add a scheduled freshness check.
5. Expose via the adapter + container binding only — no direct package imports outside the adapter.

Operational Impact

Maintenance Runtime maintenance is effectively zero — static data, no runtime state, no configuration drift. The liability sits upstream: if the maintainer is dormant, you inherit the ISO-4217 tracking burden. Budget a quarterly review plus a one-line regression test update for the 2–5 changes the standard sees in a typical year. That is a small but permanent, non-delegable cost.

Support None. No vendor, no SLA, no documented support channel, and zero dependents means no Stack Overflow corpus or blog posts to fall back on. Escalation path is "read the source" — acceptable for a 200-line data table, unacceptable if the package is ever expected to do more.

Scaling A non-issue. In-memory arrays, no I/O, no per-request overhead beyond autoloading, and fully opcache-eligible. Behaves identically at 10 req/s and 10k req/s. Any per-request lookup should still go through a cached repository binding to avoid repeated array construction in hot paths, but this is hygiene, not a scaling concern.

Failure modes

• Stale data → incorrect minor units (highest severity). Silent 100× rounding errors in financial output. Mitigation: regression tests on specific exponents plus a scheduled freshness check against the ISO list.
• Package abandonment or removal from Packagist. Breaks composer install on clean builds and CI. Mitigation: commit composer.lock, and prefer a vendored table or a Composer repositories mirror if adopted.
• Supply-chain compromise. Small, unaudited, single-maintainer packages are the canonical vector. Mitigation: exact version pin, review the diff on every update, and consider a private mirror.
• Divergent dual source of truth. If both symfony/intl and this package are consulted in different code paths, results will eventually disagree. Mitigation: single adapter, single authority.

Ramp-up Near-zero for engineers — the API surface is a lookup table, and onboarding cost is measured in minutes. The genuine ramp-up cost is governance, not learning: someone must own the adapter, the pinning policy, the regression tests, and the quarterly ISO review. For a package delivering a smallish, widely-replicated dataset, that governance overhead likely exceeds the cost of simply vendoring the table.

Recommendation: Do not adopt as a primary dependency at the current signal level (0 stars, 0 dependents, no visible CI or release history). The functional gap is already covered by symfony/intl in most Laravel installations and by moneyphp/money where arithmetic is needed. If a genuine gap exists — symbols, localized names, specific formatting — vendor the ISO table into the application under test, behind a CurrencyRepository interface, and refresh it on a schedule. That captures 100% of the value with none of the abandonment, supply-chain, or silent-drift risk. Revisit the package only if it publishes a changelog tied to ISO revisions, demonstrates CI and test coverage, and gains independent dependents.