Validation Laravel Package

Technical Evaluation

Architecture fit. respect/validation is a framework-agnostic Composer package with no Laravel service provider, no auto-discovery, and no container coupling. That makes it trivially installable but architecturally additive: Laravel already ships illuminate/validation, FormRequests, an error bag, localised :attribute placeholders, and a large rule catalogue. Adopting Respect therefore means running a second validation engine unless the need is specifically outside the HTTP boundary. The genuine architectural fit is:

• Domain/DDD layers where FormRequests should not reach (value objects, DTOs, aggregates), including v3's #[Validators\Email]-style attribute validation.
• Non-HTTP ingress: queue job payloads, console commands, webhook consumers, config bootstrapping.
• Complex conditional/nested validation that Laravel handles awkwardly — v3's shortCircuit() and factory(fn($input) => …) are the strongest differentiators, plus 150+ validators (IBAN, country/subdivision codes, phone via libphonenumber, UUID variants) that would otherwise be third-party Laravel rules.

Integration feasibility. High, at low effort for the adapter path: composer require respect/validation, then a thin class implementing Illuminate\Contracts\Validation\ValidationRule that delegates to a Respect validator. That preserves the whole Laravel pipeline (FormRequest, $request->validate(), error bag) while borrowing Respect's rule coverage. Message rendering is the one real friction point: v3 resolves messages through Symfony translation contracts, not Laravel's translator, so lang/*.php files and :attribute substitution will not apply without an adapter — expect mixed-language API errors if this is glossed over. Note that symfony/translation-contracts arrives transitively via illuminate/*, so the dependency graph itself is satisfied.

Technical risk. Ranked:

1. PHP 8.5 floor on v3. This is the gating risk, not the code. ^3.0 requires PHP 8.5+, which restricts you to the newest Laravel majors. Most production estates are on 8.2–8.4, which strands you on ^2.4 — a line whose validate(), AbstractRule, and per-rule exceptions are already deprecated and mechanically renamed in v3 (validate()→isValid(), Rules→Validators, Call→After, Nullable→NullOr, NotEmpty→Falsy, strict-by-default string comparisons).
2. validate() returns a ResultQuery, not a bool. Objects are always truthy. Any ported or mis-typed if (v::email()->validate($x)) becomes a silent accept-everything bug. This is a production-severity failure class and warrants a static-analysis rule.
3. Exception unification. v3 collapses per-validator exceptions into one ValidationException. Existing catch (EmailException) blocks stop catching and surface as 500s instead of 422s.
4. Duplicate truth. Two engines defining "valid email" identically today will diverge on upgrade, producing paths that accept what another rejects.

Key questions. Which PHP/Laravel majors are actually in production, and what is the 8.5 upgrade horizon? Is the requirement HTTP request validation (Laravel already solves this) or domain/DTO validation (Respect genuinely helps)? Do we need localised messages beyond English? How many custom Laravel rules already exist that would need porting? Who owns the adapter layer long-term? What is the exit plan — is the adapter thin enough that removal is a one-sprint job?

Integration Approach

Stack fit. Composer-only, no framework coupling; fit is "sidecar," not "replacement." Keep illuminate/validation as the HTTP boundary of record and use Respect in the domain and at non-HTTP ingress. This avoids a rewrite while capturing the rule coverage that motivated the evaluation.

Migration path. Three phases, each independently shippable:

1. Adapter (1–2 weeks). Add respect/validation under a constraint chosen by the PHP floor (^3.1 if 8.5 is live, otherwise ^2.4 with a dated v3 exit plan), a service provider binding a singleton validator factory, a RespectRule implementing ValidationRule, and a translator bridge to Laravel's Translator so messages and :attribute substitution stay consistent. Replace only rules Laravel lacks.
2. Domain layer (one sprint). Introduce Respect inside value objects and DTOs, exercised by unit tests, with shortCircuit() for dependent checks and factory() for confirmation-style comparisons against sibling input.
3. Consolidation (quarterly). Extract shared rule definitions into a single validation spec so the HTTP adapter and domain layer cannot drift; deprecate overlap deliberately rather than by accident.

Compatibility. Respect 2.4 targets PHP 8.1+, matching Laravel 10–12's floor. v3's 8.5 requirement should be treated as a forward-compatibility bet, not a current target. Both the Symfony-contracts dependency and PSR-4 autoloading are non-issues. The real compatibility surface is behavioural: v3's strict Contains/In/StartsWith, Each rejecting stdClass, and Url gaining domain/IP checks will change outcomes on existing data.

Sequencing. PHP upgrade decision → Composer constraint → adapter + contract tests → single bounded pilot (one import pipeline or one FormRequest group) → domain adoption → consolidation. Never flip HTTP validation wholesale; run both engines in parallel and diff their verdicts on production-shaped fixtures before trusting either.

Operational Impact

Maintenance. MIT, active releases (3.1.0 → 3.1.1 within the visible window) and a steady dependabot cadence, including automated "Update Regional Information" bumps. Two signals temper this: release history shows a small contributor core with one dominant committer, and the supplied metadata reports 0 dependents, which is almost certainly a data artifact but should be verified on Packagist before we treat ecosystem breadth as a safety net. The adapter, translator bridge, and rule spec are our code and must have a named owner.

Support. Community-only: GitHub issues plus Read the Docs (validator list, feature guide, and an explicit v2→v3 migration guide — genuinely good). No SLA. If we need guaranteed turnaround on a message-rendering bug, we must budget to fork or vendor. Add composer audit/GHSA monitoring to CI; the transitive surface now includes sokil/php-isocodes, ramsey/uuid, and libphonenumber-for-php-lite, each with its own release rhythm.

Scaling. Validation is pure-PHP, CPU-bound and I/O-free — negligible at our volume, assuming validator instances are built once in the container rather than per call. The non-obvious cost is the failure path: error trees and message rendering are more expensive than a boolean check, so a high-volume 4xx endpoint (abuse, bots) turns message construction into a measurable line item. Watch that specifically, and consider short-circuiting before rendering.

Failure modes to instrument.

• Truthy ResultQuery in a boolean context → silent acceptance. Guard with static analysis, not review.
• Locale mismatch between Laravel's translator and Respect's Symfony contracts → mixed-language API errors.
• Uncaught ValidationException where EmailException was expected → 500s instead of 422s; add an exception-handler mapping and alert on it.
• Rule divergence between the two engines on the same field → inconsistent accept/reject for identical input.
• PHP floor drift breaking composer install in CI on a base-image bump.

Ramp-up. The team is already fluent in Laravel validation, and Respect's fluent v::numericVal()->positive()->between(1, 255) reads familiar, so syntax is not the cost. The cost is the v3 conceptual model — ResultQuery vs isValid, named()/templated(), prefixed shortcuts, attribute validation, factory validators — and the message pipeline. Budget roughly one sprint of pairing to reach productive parity and two for the engineer owning the adapter, and publish a short internal standard on when to reach for which engine. Without that standard, the default behaviour will be to duplicate rules in both, which is the failure mode this whole assessment exists to avoid.