Validator Bundle Laravel Package

Technical Evaluation

Architecture fit — the premise needs correcting before anything else. assoconnect/validator-bundle is a Symfony bundle, not a Laravel package. It ships a Symfony DI extension, service definitions wired into symfony/validator, Constraint/ConstraintValidator implementations that depend on Symfony\Component\Validator, translation catalogues consumed by the Symfony translator (en/fr/es), and — per the release history — Doctrine ORM integration (EntityValidator, custom DBAL column types, DateTimeMicroSecondsType). It has no Illuminate\Validation service provider, no Rule objects, no Laravel translation integration. In a Laravel codebase this is a foreign runtime bolted alongside the framework's own validator, not a drop-in.

• Symfony applications: strong fit. Constraints attach to entities, DTOs, form types, and Doctrine lifecycle events with zero architectural friction. This is the intended deployment.
• Laravel applications: poor fit as a bundle. The genuinely reusable asset is the set of ~15 self-contained scalar constraint validators — email, phone, latitude/longitude, money, timezone, French RNA/SIREN/SIRET, Belgian enterprise number, EU VAT, NIF — all MIT. Most are thin wrappers over regex/checksum logic plus giggsey/libphonenumber-for-php for phone. The realistic TPM framing is selective code extraction, not dependency adoption.

Integration feasibility. Composer install plus Symfony Flex auto-registration; manual service wiring if Flex is absent. Validators are stateless and DI-friendly, so blast radius is low — they can be introduced incrementally into form handlers, API request validation, or console import jobs without touching persistence. The real friction is the version gate, not the install: recent tags require PHP 8.3+, then PHP 8.4+ from v2.42.0, and Symfony 7 only from v2.39.0 (Symfony 6 and below dropped). Any Laravel shop on PHP 8.1–8.3 is excluded outright or pinned to a stale tag.

Technical risk.

• Version-lock exposure dominates. The maintainer tracks the latest PHP and Symfony aggressively rather than holding a compatibility band. Every framework upgrade becomes a dependency you must chase, and with 5 stars / 0 dependents you will not find compatibility patches pre-made by the community.
• Single-vendor stewardship. One organization releasing rapidly (45+ minor releases, many tied to internal tickets like IT9PE1-*). Effective bus factor of one or two maintainers. MIT limits the downside (you can fork) but a fork is a standing maintenance commitment.
• Metadata anomaly. The stated last release date (2026-10-08) is future-dated. Treat release-cadence and lifecycle signals as unverified until checked against the real tag list; do not approve on them.
• Transitive surprise. giggsey/libphonenumber-for-php jumped ^8.13 → ^9.0 inside a patch release (v2.42.2). Phone parsing semantics and metadata size moved under a non-major bump — the classic source of a silent production validation regression.
• Regional ceiling. Coverage leans francophone/Benelux/Iberian. For a US/UK/APAC product, email/phone/lat-long/money/timezone carry all the value and the identifier validators are dead weight.
• Thin documentation. The README delegates options to "see the constraint source code." Acceptable for an internal bundle; a real onboarding cost for a team.
• Translation coupling. Messages assume Symfony's translator; a Laravel port loses the catalogue and any locale coverage unless you rebuild it.

Key questions.

1. Is the target application Symfony or Laravel? If Laravel, are we funding a ported copy of specific constraint classes instead of taking a dependency?
2. What is our PHP floor and mandated upgrade cadence — can we absorb a package that requires PHP 8.4 today?
3. Which constraints do we actually need? If it is only email/phone/money/timezone, this is a heavier dependency than the problem.
4. Are French/Belgian/Iberian identifiers in scope for the next 24 months, or speculative?
5. Do we accept forking under MIT if upstream stalls or jumps PHP again?

Integration Approach

Stack fit.

• Symfony target: adopt as designed. composer require assoconnect/validator-bundle, let Flex register the bundle, apply constraints as PHP attributes on DTOs/entities, and register the Doctrine types only if you want column-driven validation.
• Laravel target: do not install the bundle. Treat the repo as a reference implementation. Extract the constraint validators you need into App\Validation\Rules\* implementing Illuminate\Contracts\Validation\ValidationRule, preserving the MIT license header and upstream attribution. Phone is the one non-trivial port — it depends on libphonenumber-for-php, which is framework-agnostic and installs cleanly alongside Laravel.

Migration path.

1. Inventory existing custom validators and regex checks. Map each to an upstream constraint or mark it as "no equivalent."
2. Pilot one constraint in a non-critical path (e.g. timezone or money) to prove the wiring end to end.
3. Replace highest-churn logic — French SIREN/SIRET/RNA checksums and phone parsing are where hand-rolled regex bugs concentrate and where the package pays for itself.
4. Retire bespoke regex utilities only after their tests are ported and green.
5. Decide the fork question explicitly at the start; do not drift into one.

Compatibility.

• Pin PHP floor and pick the newest tag that satisfies it; do not chase HEAD.
• On Laravel, verify PHPUnit/PHPStan configs in the extracted code do not drag in assoconnect/php-quality-config.
• Port the en/fr/es message catalogue into lang/ if localized validation errors are user-facing.
• Check Doctrine integration not used if you are Laravel + Eloquent — none of the ORM/DBAL surface applies.

Sequencing. Pilot (1 sprint) → one bounded domain (2–3 sprints) → general adoption or fork-and-vendor → upstream pin review at each PHP/Laravel upgrade cycle. Extract, don't wrap, on the Laravel side: a shim layer that reimplements Symfony constraint contracts is the highest-cost, lowest-value option.

Operational Impact

Maintenance. Low code volume, low change frequency, but high version-chase cost. Pin exact versions in composer.json, subscribe to releases, and budget a review each PHP and framework major. Keep the fork path warm — a vendored copy under our namespace removes the upgrade treadmill entirely at the cost of losing upstream fixes (which are mostly new regional identifiers).

Support. No SLA, no vendor contract. GitHub issues on a 5-star repo mean best-effort, single-timezone response. For a compliance-adjacent use case (VAT numbers, business identifiers) that is a real consideration: if a validator is wrong, the fix timeline is ours, not theirs.

Scaling. Negligible runtime cost. Validators are pure functions over strings. The one footprint item is libphonenumber-for-php metadata (~tens of MB unminified); on PHP-FPM it is fine, on constrained container images check image size. No state, no cache invalidation, no external calls — this is the package's strongest operational property. Latency is microseconds; throughput scales linearly and never becomes a bottleneck.

Failure modes.

• Silent translation fallback for an unpopulated locale — upstream caught this once (Spanish catalogue missing), which implies it can recur with new constraints.
• Dependency drift under a patch bump (the libphonenumber v9 move) surfacing as a validation regression rather than a build error.
• Upstream abandonment or another PHP jump, forcing an unplanned fork.
• Over-strict validation rejecting legitimate user input — checksum validators on real-world dirty data (leading spaces, legacy formats) are a common source of support tickets.
• Doctrine auto-validation surprise in a Symfony app where column types trigger validation you did not explicitly request.

Ramp-up. Small — roughly 15 short classes and a doc directory. A mid-level engineer can read the relevant validators in half a day. Budget one to two days for the Laravel extraction path per constraint family, plus a day to re-establish the message catalogue and tests.

Recommendation. Adopt on Symfony if French/Benelux identifiers are in scope; consider it a credible convenience dependency. On Laravel, treat it as a source of MIT-licensed logic to extract, not a component to integrate — and make that decision explicitly rather than discovering it during implementation.