Eori Laravel Package

Technical Evaluation

Architecture fit. slimad/eori is a single-purpose Laravel validation package. Its natural seat is the input-validation layer: a FormRequest, a Rule object, or a Filament/Livewire field validator on any onboarding, KYC, or B2B registration flow that captures an EU customs identifier. Footprint is small and stateless, which is good — it does not introduce a service, queue, or persistence concern by itself.

The critical architectural distinction is syntax validation vs. existence validation. EORI format is country-prefixed (2-letter ISO country + up to 15 alphanumerics) with per-member-state rules. Existence checking requires a call to the European Commission's EORI registry, which is network-bound, rate-limited, and has no consumer SLA. These two behaviors belong in different layers: format checks are safe in synchronous request validation; existence checks must be asynchronous (queued job, cached result, retry policy) or they will degrade your p95 latency and couple your onboarding to a third-party endpoint. Confirm which one the package implements before committing to an integration point.

Integration feasibility. Low-effort. Standard Composer install, Laravel package auto-discovery, likely a publishable config and a rule alias. A single engineer can spike it in an afternoon. The real work is not integration but verification: the release (2024-07-16) predates Laravel 12, so the Composer constraints against your PHP/Laravel matrix must be checked explicitly rather than assumed.

Technical risk.

• Adoption risk (high). 0 stars and 0 dependents means effectively zero production evidence. There is no external signal that this code has ever run in anger.
• Maintainer risk (high). Single-maintainer, no organizational backing. Bus factor of one. MIT license at least means you can fork and vendor it, so this is mitigable rather than fatal.
• Data staleness risk (medium-high). EORI formats are not static. Brexit split GB from the EU scheme and introduced XI for Northern Ireland; accession and national rule changes recur. A hardcoded country table has a shelf life. If the table is data-driven and updatable, this drops to low.
• Remote-dependency risk (conditional, high). If the package performs live registry lookups, you inherit the Commission's endpoint stability, schema, and rate limits as your own reliability surface.
• Supply-chain risk (low). Small package, MIT, no transitive weight worth worrying about — but it is unvetted code, so read it before shipping.

Key questions to answer before approval.

1. Does it validate format only, or does it perform a registry existence check?
2. Which Laravel and PHP versions are declared in composer.json? Is there a CI matrix?
3. Is the country-format table hardcoded, config-published, or externally sourced — and how is it updated?
4. Are GB and XI (post-Brexit) handled correctly?
5. What is the test coverage, and does it include known-valid and known-invalid EORI fixtures per country?
6. Is it exposed as a validation rule, a facade/service, or both?
7. Any catastrophic-backtracking risk in the regexes? Is input length bounded?

Integration Approach

Stack fit. Conventional Laravel package shape: service provider, config, validation rule. Drops into existing FormRequest rules, custom Rule objects, API request validation, and admin-panel validators without touching your domain layer. No conflict with typical Laravel stacks.

Migration path. There is nothing to migrate from — this is greenfield. Equally, the exit cost is near zero: a per-country regex table plus a rule class is roughly a day of work in-house. Treat the package as a convenience, not a dependency. The decisive move is to wrap it behind your own EoriValidator contract so that swapping to an in-house implementation, or to a different package, is a one-class change and not a codebase sweep.

Compatibility. Pin an exact version in composer.json rather than floating. Add it to your dependency-review checklist and run its suite (or your own contract tests) against your supported Laravel/PHP matrix in CI. If you are on Laravel 12, assume incompatibility until proven otherwise and verify explicitly.

Sequencing.

1. Spike in a feature branch: install, run known-valid and known-invalid EORIs (one per major country, plus GB and XI).
2. Determine format-vs-existence behavior empirically from the code and from a deliberately fake-but-well-formed number.
3. Introduce an internal adapter interface and a thin implementation delegating to the package.
4. Write contract tests with a fixture set of real and malformed EORIs; these become your regression harness if you later fork or replace.
5. If existence checks are involved, route them through a queued job with caching and a documented fail-open/fail-closed policy — do not call them inline in the registration request.
6. Ship behind a feature flag; monitor rejection rates by country in the first two weeks to catch false negatives.

Operational Impact

Maintenance. Code churn is likely minimal, but the data is perishable. Budget roughly half a day per year to re-verify the country-format table against current EU and UK rules, and a defined trigger to review whenever EU membership or customs arrangements change. Because it is MIT with no dependents, the realistic path on abandonment is to fork the rule class and own it — cheap, but should be a documented decision, not an improvisation.

Support. Community-only. No vendor, no SLA, no escalation path beyond the maintainer's inbox. Operational ownership of any incident defaults to your own team, so the runbook must assume internal diagnosis.

Scaling. Format validation is CPU-trivial, stateless, and horizontally safe — negligible cost at any realistic volume. If existence checks are in play, throughput is bound by the Commission's endpoint, not by your infrastructure: cache positive and negative results with a sane TTL, batch where possible, and keep lookups out of the synchronous request path for bulk onboarding or imports.

Failure modes and mitigations.

• Stale country table → false negatives that block legitimate businesses at signup. Mitigation: log every rejection with the raw input and country code; alert on rejection-rate anomalies.
• Over-permissive regex → invalid identifiers pass validation and fail later at customs, which is a worse and more expensive failure. Mitigation: validate against a curated fixture set, not just ad-hoc examples.
• Remote API timeout or outage (if applicable) → decide fail-open vs. fail-closed per use case: fail-open plus a manual review queue is usually correct for onboarding; fail-closed for anything with financial or compliance consequence.
• ReDoS on adversarial input → bound input length before validation and inspect the regexes for nested quantifiers.
• Package abandonment → mitigated by the adapter boundary and a vendored fork path.

Ramp-up. Hours for any Laravel developer to integrate; roughly a day to do it properly with the adapter, fixtures, and feature flag. The knowledge that must persist is small but specific: which EORI formats are covered, whether existence checks occur, and what the failure policy is. Put those three facts in the runbook — they are the only things a responder will need when EORI validation starts rejecting valid customers at 2 a.m.