Extra Validator Bundle Laravel Package

Product Decisions This Supports

• Market expansion into Spain (and Spanish-speaking LatAm adjacent flows). The package encodes two validation rules that appear in nearly every Spanish-facing signup, checkout, or invoicing flow: postal code format and personal/fiscal identifiers (DNI/NIE/CIF). If the roadmap contains a "launch in Spain" or "self-serve billing for Spanish customers" epic, this is a small but real build-vs-buy decision to make inside it — and the answer from the evidence is "build."
• Data-quality and fraud gating at the form boundary. Rejecting malformed or checksum-invalid identifiers at registration, trial signup, or seller onboarding reduces junk accounts, failed invoices, and downstream manual cleanup. This is a cheap, deterministic first line of defense — no third-party API call, no per-lookup cost.
• Invoice and tax compliance readiness. Spanish B2B invoicing requires a valid fiscal ID on the customer record. Validating at capture (rather than at invoice generation) moves a recurring support/back-office failure mode earlier in the funnel, where it is cheaper to fix.
• Build vs. buy vs. port. The core value here is not code volume — the checksum algorithms are short, publicly specified, and stable. As a PM I would frame the decision as buy the spec, build the rule: harvest the DNI/NIE/CIF and postcode logic (~100–250 lines) into first-party Laravel ValidationRule objects rather than adopting the package.
• Framework-fit check as a strategic signal. Despite being filed under the Laravel/PHP track, this is a Symfony 2 bundle — no service provider, no Illuminate\Validation\Rule, no config publish hook. Symfony 2 has been end-of-life since 2018. That mismatch is itself a product decision: we would be adopting packaging built for a framework generation we don't run, to get four regex/checksum functions.
• Use cases worth scoping: Spanish address capture at checkout; marketplace seller/autónomo onboarding; B2B account creation with VAT/NIF fields; lead-form hygiene for the Spanish sales team.

When to Consider This Package

Consider it when:

• We are maintaining or extending a legacy Symfony 2.x application (or a hybrid stack already using Symfony Validator constraints) and need Spanish postcode / ID validation with minimal ceremony.
• We need the validation logic quickly for a prototype or internal tool, and the team is comfortable pinning it and replacing it later.
• We want a reference implementation of the DNI/NIE/CIF checksum rules to sanity-check our own implementation or to derive test fixtures — reading it is arguably more valuable than depending on it.
• We need only offline format/checksum validation for one country and don't require authoritative tax-authority verification.

Look elsewhere when:

• We are a Laravel shop building new surfaces. Use a Laravel-native validation rule (custom ValidationRule object or a maintained rules package). The Symfony 2 bundle plumbing is dead weight, and the constraint classes are trivially portable.
• Maintenance and security posture matter. The signals are weak across the board: 9 stars, 0 dependents, composite score 0.315, and a Symfony 2 target that has been EOL for years. Zero dependents means no ecosystem has pressure-tested it — we would be the first. Expect Composer pin conflicts (php: >=5.3, symfony/symfony: ~2.x) against any Laravel 10+ / PHP 8.1+ app, and constraint APIs (getDefaultOption/setDefaultOption) removed in Symfony 3.0.
• We need more than Spain. No multi-country coverage, no locale negotiation, no address normalization — just format/checksum validation for one country.
• We need canonical, authoritative validation (e.g., actual VIES/NIF verification). This is format validation only; it does not prove the entity exists or is active.
• Licensing, ownership, or bus-factor review is a blocker. There is a single maintainer, negligible adoption, and a package/repository name mismatch (ideup/extra-validator-bundle vs javiacei/ExtraValidatorBundle) that creates provenance ambiguity. Treat it as unmaintained code and plan to own it — fork it or reimplement.

How to Pitch It (Stakeholders)

To executives (one paragraph): For our Spain-facing flows we need to validate Spanish postcodes and fiscal IDs (DNI/NIE/CIF) at the point of capture. An existing open-source PHP package does this, but it is a small, low-adoption Symfony 2 bundle — 9 stars, zero dependents, built for an end-of-life framework — so adopting it would mean taking on an unmaintained dependency with no security or support path. The business capability is worth having; the dependency is not. My recommendation is to take the well-documented checksum rules and implement them as a small, owned validation rule in our Laravel codebase: roughly 1–2 engineering days plus tests, no third-party maintenance or security exposure, no licensing review, and full test coverage on our side. Net cost is comparable to adopting the package and materially lower risk.

To engineering: Treat ideup/extra-validator-bundle as a specification and reference, not a dependency. There is no Laravel integration surface — the correct framing is harvest the algorithm, discard the packaging. Extract the DNI/NIE/CIF and postcode checksum logic into first-party Laravel ValidationRule classes (SpanishDni, SpanishNie, SpanishCif, SpanishPostcode) with Pest/PHPUnit data providers over a known-good/known-bad vector table — valid and invalid DNI, NIE with each of X/Y/Z, CIF across the control-letter and control-digit branches, boundary postcodes (01000/52999), plus negatives for whitespace, lowercase, and 9-digit inputs. Flag two limits in the ticket: this validates format only, not tax-authority existence; and postal-code validation should be paired with country selection so we don't misapply Spanish rules to non-Spanish addresses. Sequence the port before any surface depends on Spanish tax identifiers — if a release is imminent, ship a permissive format-only regex first and tighten to checksum validation the following sprint. Watch for silent false negatives (legitimate NIEs/CIFs rejected by logic that may predate post-2008 identifier reforms) — mitigate with a canary cohort and a manual-override path, and record validation outcomes since DNI/NIE are personal data under GDPR/LOPDGDD. Budget ~3 developer-days for spike, port, and tests, plus a review pass by someone with Spanish-market domain knowledge. If we do vendor any code, pin it, note origin and license in the repo, and add it to third-party review — we own it from day one.

The ask: Approve the small build (est. 1–2 engineering days plus tests, ~3 days end-to-end) inside the Spain launch epic, assign a named owner for the extracted rules, and skip adding the Symfony 2 bundle as a production dependency. Score 0.315 with 0 dependents and an EOL framework baseline is a clear no-go for adoption; close the evaluation once the port lands.