Laravel Int Laravel Package

Technical Evaluation

Architecture fit epigra/laravel-int sits at the presentation/formatting edge of the stack, not in the domain core. Based on the description and Epigra's package family conventions, it is a thin convenience layer over PHP's intl extension (ICU NumberFormatter, IntlDateFormatter, MessageFormatter, locale negotiation) exposed via a Laravel service provider, facade, and/or global helpers. That is a favorable architectural position: low coupling, no persistence, no queues, no cross-cutting state. It can and should be isolated behind an internal formatting/localization contract so the application's business logic never imports the package directly. It is not an i18n translation management tool — do not expect it to replace laravel-lang, spatie/laravel-translatable, or a translation-CMS workflow; assume it complements them.

Integration feasibility Mechanically trivial: composer require epigra/laravel-int, package auto-discovery registers the provider, optional config publish. The real gating items are environmental, not code-level: the intl extension must be present and identically versioned across local, CI, container, and production images, and ICU data must be available in the runtime image. A one-day spike is sufficient to confirm. The absence of a documented Laravel version support matrix is the main unknown to resolve before committing.

Technical risk The dominant risk is vendor/project maturity, not technology. Zero stars, zero dependents, and no score signal means effectively no community validation, no third-party battle-testing, and no observable ecosystem of people who will find and report defects before we do. Practical implications:

• Single-maintainer abandonment risk is high; assume we may inherit maintenance.
• Public API stability is unverified — helper signatures, config keys, and fallback semantics could shift between minor releases.
• No dependents also means no downstream compatibility pressure, so Laravel major-version support may lag.
• Security exposure is inherently low (no network I/O, no deserialization, no auth surface), so the risk profile is "breakage and drift," not "compromise."

Blast radius is contained: because the package only produces display strings, a failure degrades formatting, not correctness of stored data or transactions — provided we never persist its output as a canonical value.

Key questions

1. What exactly is the API surface — number, currency, date/time, relative time, message formatting, locale detection? Which of these do we actually need versus raw intl?
2. What Laravel and PHP versions are declared in composer.json, and is there a CI matrix proving them?
3. Test coverage and test quality — is there a suite, and does it cover locale fallback and edge locales (ar, hi-IN, de-CH, RTL)?
4. Who maintains it, what is the commit cadence over the last 12 months, and what is the license?
5. Is intl already a hard requirement of our other dependencies (it likely is, via laravel-money/laravel-phone), or is this package introducing it?
6. Does it handle locale negotiation (Accept-Language → app locale → fallback) or does it assume App::getLocale() is already correct?
7. Is there a documented behavior for invalid locale or missing ICU data — exception or silent fallback?

Integration Approach

Stack fit Fits cleanly into a standard Laravel app that already performs per-request locale resolution and already ships the intl extension. It is a particularly natural companion if we are also evaluating epigra/laravel-money or epigra/laravel-phone — but that is a reason to standardize on the vendor, not a reason to accept the risk of each package independently. Treat the Epigra family as one dependency decision with one risk envelope.

Migration path Adopt behind an internal seam from day one. Define a small application-owned interface — e.g. App\Support\Formatting\Formatter with number(), currency(), date() — and implement it with this package. This costs roughly half a day and reduces a future swap to raw NumberFormatter/IntlDateFormatter or an alternative library to a single class change. For brownfield code, do not bulk-replace existing number_format()/Carbon::format() call sites; convert opportunistically per feature area so regressions are attributable.

Compatibility Verify three things before merge: (a) declared Laravel constraint covers our current and next major version, (b) no collision with existing localization packages over helper names, config keys, or the intl bootstrap, and (c) the intl extension and ICU version are pinned in the base Docker image and CI runner so local and production formatting agree byte-for-byte. Pin the package to an exact version (not a caret range) until we trust its semver discipline.

Sequencing

1. Spike (1–2 days): install in a branch, exercise every helper we intend to use against our real locale set, confirm intl in all environments.
2. Interface: land the internal Formatter contract and adapter, with a test asserting fallback behavior for an unsupported locale.
3. Pilot (1 sprint): convert one visible surface — currency on an invoice/report screen is the usual best candidate because errors are obvious and low-consequence.
4. Expand: roll out to dates and numbers per feature area.
5. Document: record the decision, version pin, and swap-out procedure in an ADR.

Operational Impact

Maintenance Plan to own this code within 12–18 months. Budget a few hours per quarter to review upstream activity and per Laravel major upgrade to validate compatibility — and hold a fork-and-vendor contingency if the upstream goes quiet. Because the surface is small and the underlying intl calls are stable, forking is cheap; this is the main reason the risk is tolerable at all.

Support No SLA, no vendor contact, GitHub issues only. Internal support therefore depends entirely on our own documentation and the seam described above. Any engineer should be able to answer "what formats our currency, and how do I change it?" without reading the vendor source.

Scaling Runtime cost is negligible — intl is a C extension and formatting is microseconds. The one real scaling consideration is per-request object churn if the package instantiates formatters on every call; batch formatting in loops or memoize per locale. There is no state, no cache, no I/O, so horizontal scaling is a non-issue.

Failure modes

• intl missing or ICU data absent in a container → fatal error or, worse, silent degradation to English/US formatting on the first request after deploy. Mitigate with a startup health check that formats a known string in a non-default locale.
• Unsupported locale → silent fallback to root locale, producing subtly wrong output (wrong decimal separator, wrong date order) that passes tests and reaches customers. Mitigate with assertion tests across the actual locale list.
• Version pin drift across services → different services rendering the same value differently. Mitigate with a shared composer constraint and a shared base image.
• Locale set before the formatter is resolved (middleware ordering) → formatting in the wrong locale for the whole request. Mitigate by resolving locale before any formatting call and testing middleware order.
• Persistence misuse: someone storing formatted output as a canonical value. This is the highest-consequence failure and is a code-review/architecture concern, not a package concern — enforce "format at the boundary" in review.

Ramp-up Low. A competent Laravel engineer is productive in half a day. The learning cost is not the package but the underlying ICU semantics — locale negotiation order, CLDR differences, and the fact that "formatted correctly" varies by locale in ways that are invisible to a US-centric reviewer. Pair the adoption with a short internal note and a test suite seeded with real locales; that note is the durable artifact, not the package documentation.

Recommendation Technically low-risk, organizationally unproven. Approve for a bounded pilot behind an internal abstraction with an exact version pin, contingent on the spike confirming intl parity across environments and a declared Laravel constraint that covers our upgrade horizon. Do not adopt it as a deep, unabstracted dependency across the codebase given zero external dependents.