Validator Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for scalar validation. Every product team eventually writes the same validators: is this email deliverable-shaped, is this phone number parseable, is this IBAN/VAT/SIRET well-formed, is this latitude within ±90. This package is the buy-side answer for the ~15 checks it covers, and the decision it most directly informs is "do we write these ourselves or adopt a library?" For a Symfony shop, the honest answer is adopt; the build cost is small but the edge-case cost is not — SIRET Luhn checks, Belgian enterprise-number mod-97, EU VAT country prefixes, and phone metadata are all places where a hand-rolled regex passes code review and fails production.
• Scope decisions on geographic expansion. The constraint inventory is a readable map of where the maintainers' product operates: French RNA/SIREN/SIRET, Belgian enterprise number, Spanish NIF, EU VAT, alongside generic email/phone/lat-long/money/timezone. If your roadmap includes France, Belgium, or Iberia — onboarding merchants, invoicing, KYC, business-registry lookups — this package covers a meaningful slice of the "do we need to build localization for this market?" question. If your roadmap is US/UK/APAC, five of the constraints are the entire value and the identifiers are dead weight.
• Roadmap input on engineering standards, not features. The release history is a forcing function: PHP 8.4 required from v2.42, Symfony 7-only from v2.39, Symfony 6 and PHP 8.2 dropped in minor releases. Adopting this package is an implicit commitment to a fast upgrade cadence. That belongs in a platform-modernization conversation, not a feature backlog.
• Use cases it unlocks cheaply: signup and profile forms (email, phone, timezone), checkout and billing (money, EU VAT, SIREN/SIRET for B2B invoicing), address capture and maps (lat/long, postal with country property path), import/ETL pipelines where you want to reject bad records at the boundary rather than discover them downstream.
• What it does not decide. It is not a data-quality platform, not a verification service (no SMTP probe, no VAT lookup against VIES, no address normalization), and not a replacement for a phone-number product if phone is a core input. It validates shape and checksum, not truth.

When to Consider This Package

Consider it when:

• The application is Symfony 7+ and the team is already on the Symfony Validator and comfortable with constraint attributes on entities and DTOs. Here it is close to zero-friction: install, annotate, done.
• You need two or more of the specific checks it ships — realistically that means French/Belgian/Spanish business identifiers or EU VAT are on your near-term roadmap. One constraint alone does not justify a dependency.
• Your PHP floor is 8.4+ and you have a credible path through Symfony minor upgrades. Recent tags are not forgiving of laggards.
• You accept single-vendor, low-adoption stewardship (5 stars, zero dependents, one organization, MIT). The license makes the downside bounded — you can fork — but budget the fork as a real option, not a comforting footnote.
• You want validators, not verifiers. If all you need is "reject obviously malformed input before it hits the database," this is proportionate.

Look elsewhere when:

• The stack is Laravel. This is the single biggest disqualifier, and it should be stated plainly: this is a Symfony bundle — a DI extension, service definitions, and classes bound to symfony/validator's ConstraintValidator contract. There is no Laravel service provider and no Illuminate\Validation rule objects. In Laravel you are either (a) using Laravel's built-in rules plus a dedicated library like propaganistas/laravel-phone and a VAT/SIRET rule package, or (b) deliberately extracting the MIT-licensed validator classes and owning a port. Option (b) is defensible and occasionally the right call, but it is a code fork decision, not an adoption decision, and it should be scoped and resourced as such.
• You only need email, phone, money, or timezone. Symfony ships Email, Timezone, and Currency constraints already; Money and better phone handling you can get from a focused single-purpose package. Pulling a bundle with an aggressive upgrade cadence to use one generic check is a poor trade.
• You are on PHP 8.1–8.3 or Symfony 6 and cannot move. You would be pinned to an old tag with no community pressure to backport fixes — zero dependents means you are the only one who will notice a break.
• You need verification, not format validation. No email deliverability, no VAT-in-force lookup, no phone carrier check, no address standardization.
• Documentation depth matters for your team. The README defers options to "see the constraint source code." Acceptable for a small team that reads PHP; a real onboarding tax for a large or rotating team.
• Your compliance posture requires maintained, widely-adopted dependencies with a security-response commitment. There is no stated security policy or support window here.

Two things to verify before any commitment: the release metadata reports a last-release date in the future (2026-10-08), which means the lifecycle signals in this evaluation should be treated as unverified until checked against the actual tag list; and note that a phone-parsing dependency (giggsey/libphonenumber-for-php) jumped ^8.13 → ^9.0 inside a patch release — the sort of change that surfaces as a silent validation regression rather than a composer error.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version. This is a small, free (MIT), open-source library of input validators for common business data — email, phone, coordinates, money, timezone, and European company and tax identifiers (French SIREN/SIRET/RNA, Belgian enterprise number, Spanish NIF, EU VAT). It is a build-versus-buy shortcut: it saves our engineers from hand-writing checksum logic that is easy to get subtly wrong and expensive to debug in production. The catch is that it is built for Symfony, not Laravel, and it is maintained by a single small organization with almost no external adoption. So the recommendation is narrow and honest: if we are on Symfony 7+ and European business identifiers are on our roadmap, this is a cheap, proportionate win. If we are on Laravel, we should not adopt it as a dependency — the sensible move is to lift the handful of validator classes we need under the MIT license and own them.

For engineering — the practical framing.

• Fit: Symfony 7+, PHP 8.4+. If we are not there, stop; the version gate is hard and recent minor releases have dropped Symfony 6 and PHP 8.2–8.3 outright.
• Cost of adoption: near zero integration effort (constraints are stateless, DI-friendly, usable in forms, DTOs, and console jobs), plus a recurring cost: we inherit the maintainer's upgrade cadence. Every PHP and Symfony bump becomes a package-compatibility task we own, and with zero dependents we will not find fixes pre-made.
• Cost of the alternative: a Laravel port or a from-scratch implementation. Realistically a few days for the handful of constraints we would actually use, plus permanent ownership of checksum logic and phone metadata. That is not obviously worse — it removes the version-lock exposure entirely.
• Risk posture: MIT means the worst case is "we fork," which is a bounded, budgetable outcome. Single-vendor stewardship and thin documentation (options live in the source, not the README) are acceptable for a small team and a liability for a large one.
• What I need from you: (1) confirm the target stack is Symfony 7+ on PHP 8.4 — if it is Laravel, this becomes an extraction project and needs its own estimate; (2) confirm French/Benelux/Iberian identifiers are in scope for the next 12–24 months, not speculative; (3) verify the actual tag history and dependency constraints against the repo, because the lifecycle metadata we were given is internally inconsistent.

Bottom line for the decision log: Adopt as a dependency in Symfony 7+ codebases where European business-identifier validation is a real near-term requirement; otherwise extract the three or four validator classes we need under MIT and own them. Do not treat this as a Laravel package.