Extra Validator Bundle Laravel Package

Technical Evaluation

Architecture fit. As published, this is a Symfony2 bundle — it targets Symfony's Validator component via service tags and a DependencyInjection\Extension, not Laravel's validator. There is no ServiceProvider, no ValidationRule, no config-publish hook, no facade. For a Laravel-first roadmap this is a framework-generation mismatch, not a minor packaging gap. The product value is real (Spanish postcode and DNI/NIE/CIF checksum validation at capture), but the delivery vehicle is wrong for our stack. My framing for stakeholders: buy the specification, build the rule.

Integration feasibility. Adoption as a dependency is not viable; extraction is. The underlying logic — DNI (8 digits + mod-23 letter), NIE (X/Y/Z prefix + 7 digits + mod-23 letter), CIF (entity-type-dependent control character), and Spanish postcodes (5 digits, province 01–52) — is roughly 100–250 lines of deterministic PHP. Porting to four invokable Laravel rules is a 1–2 day engineering task with a test suite. Bridging symfony/validator into a Laravel app to obtain four regex/checksum functions imports a large unrelated dependency tree for negligible benefit.

Technical risk — high. Symfony 2.x has been end-of-life since 2018; the constraints likely use getDefaultOption/setDefaultOption APIs removed in Symfony 3.0, and Composer pins probably conflict with PHP 8.1+ / Laravel 10+. Signal quality is poor across the board: 9 stars, 0 dependents, composite score 0.315, and a package/repository name mismatch (ideup/extra-validator-bundle vs javiacei/ExtraValidatorBundle) that muddies provenance and ownership. No visible CI or test suite.

Key questions to resolve before any decision:

1. What is the license, and does it permit vendoring the logic into our proprietary codebase?
2. Are there reusable test fixtures, or must we derive expected vectors independently?
3. Does the bundle carry anything beyond the four validators (form types, translations, DI wiring) we would lose by extracting?
4. Are the CIF/NIF rules current with post-2008 legal-entity identifier reforms?
5. Does it correctly handle NIE X/Y/Z prefixes, CIF control-letter vs control-digit branches, and Canary Islands / Ceuta-Melilla postcodes?

Integration Approach

Stack fit. None out of the box. The correct posture is "harvest the algorithm, discard the packaging." The extracted rules become framework-agnostic pure PHP behind Illuminate\Contracts\Validation\ValidationRule, which fits Laravel 9–12 and PHP 8.1–8.4 with negligible risk.

Migration path (recommended):

1. Spike (0.5 day): read the four constraint/validator pairs; confirm algorithms against a hand-built vector table (valid/invalid DNI, NIE for each prefix, CIF across letter classes, boundary postcodes 01000/52999, malformed inputs).
2. Port (1–2 days): implement SpanishDni, SpanishNie, SpanishCif, SpanishPostcode as first-party rules with translatable :message() output; ship in app/Rules or an internal package.
3. Test (0.5 day): Pest/PHPUnit data providers over the vector table plus a negative set (whitespace, lowercase, 9-digit inputs).
4. Retire upstream: no runtime reference to the original repo.

Compatibility. The ported rules are stateless, dependency-free, and framework-light — no DB, queue, or cache interaction. A bridge spike against symfony/validator: ^6|^7 is not worth scheduling; expect it to fail and be prepared to fork anyway.

Sequencing. Port and test before any product surface (Spain checkout, seller onboarding, B2B VAT capture) depends on Spanish tax identifiers. Do not gate onboarding or KYC flows on the upstream package while the port is in flight. If a launch date is fixed, ship a permissive format-only regex first and tighten to checksum validation the following sprint. Pair the postcode rule with explicit country selection so Spanish rules are never misapplied to non-Spanish addresses.

Operational Impact

Maintenance — the dominant cost driver. Upstream is effectively abandoned: no PHP 8 fixes, no security patches, no issue response. Any adoption creates a permanent internal fork-ownership obligation with zero upstream leverage. The extraction approach inverts this to ~200 lines of deterministic logic any mid-level engineer can own, with a test suite as the maintenance contract.

Support. No vendor, no SLA, no release cadence. Depending on the Symfony2 pins would also generate recurring composer audit noise, eroding trust in security tooling more broadly.

Scaling. Non-issue. Validation is stateless, CPU-trivial, in-process; not a bottleneck at any realistic request volume.

Failure modes to plan for:

• Silent false negatives — valid NIEs or CIFs rejected because the original logic predates identifier reforms, blocking legitimate Spanish users at signup. Highest-severity; mitigate with a canary cohort and a manual-override path.
• False positives — regex-only paths accepting checksum-invalid strings, quietly degrading the data quality that downstream KYC/AML depends on.
• Compliance exposure — DNI/NIE are personal data under GDPR/LOPDGDD; log validation outcomes and reasons with the record so rejections are defensible, and preserve any license notices on extracted code.

Ramp-up. Technical ramp is low — the domain logic is compact and well-documented in Spanish tax law. The real ramp is organizational: assign a named owner for the extracted rules and treat the test-vector table as the source of truth. Budget ~3 developer-days total plus a review pass from someone with Spanish-market domain knowledge before go-live.

Recommendation. Do not adopt ideup/extra-validator-bundle as a production dependency. Score 0.315 with 0 dependents on an EOL framework baseline is a clear no-go. Harvest the four validation algorithms into first-party Laravel rules with a test suite, fold the work into the Spain launch epic, and close the evaluation.