Validation Laravel Package

Technical Evaluation

Architecture fit. Unchanged by 2.3.0. selective/validation implements the notification pattern: validation rules append errors to a Notification object that the caller inspects, rather than throwing or returning a boolean. Architecturally this is a good match for a domain/application layer where validation must be reusable across HTTP, console, queue workers, and imports — a genuine gap in Laravel, whose Validator is tightly coupled to the request lifecycle, MessageBag, and framework localization. It remains a poor fit as a replacement for Laravel's HTTP-boundary validation, where FormRequests, $request->validate(), @error Blade directives, Inertia error props, and implicit rules are load-bearing. The realistic fit is still narrow: a bounded context (bulk import, multi-step wizard, queue job payload validation) that needs to accumulate all errors and hand them back as a value object.

Integration feasibility. Unchanged. 2.3.0 adds no Laravel service provider, facade, or documented bridge — it is a PHP-version compatibility release only. Integration still means writing an adapter (~100–200 LOC) that maps the package's notification errors into a Laravel MessageBag and a ValidationException so existing error rendering, API 422 responses, and Inertia props keep working unchanged. That is a one-to-three-day engineering task plus contract tests — feasible, but bespoke glue the team owns forever.

Technical risk. High relative to value, and 2.3.0 does not materially move this. The release adds PHP 8.5 support (credit @heinrichschiller), which is a positive but single maintenance signal: it shows the maintainer is tracking the PHP release train and that the version constraint is not frozen at an aging floor/ceiling. It does not address the substantive risks: 35 stars and zero dependents still means essentially no production evidence at scale, and the bus factor still looks like one. Critically, the release adds no new rules — the rule-coverage gap (DB-aware unique/exists, password, confirmed, implicit rules, localization, nested/array handling) is entirely untouched, and that gap was the primary technical objection. The package remains pure validation logic (low direct security surface), so the risk is not exploitation but abandonment and supply-chain drift — a future PHP major bump or an adapter-breaking change with no upstream release leaves us maintaining a fork. The more insidious risk remains behavioral divergence between Laravel's validator and this one for the same field.

Key questions for engineering. (Revised to reflect 2.3.0.)

• Does it cover the rules we actually need, especially DB-aware (unique, exists) and nested/array validation? Still unanswered — 2.3.0 added no rules.
• What are the PHP version constraints? Narrowed: PHP 8.5 is now supported, so the ceiling is not a blocker; confirm the floor against our runtime.
• Does it conflict with anything in our lockfile, including selective/base?
• How are nested structures and error paths represented — can they map cleanly to MessageBag keys?
• Is there localization support, or do we own message translation?
• Who maintains it, and what is the release cadence? One data point now: a compat release. Ask whether bug reports and PRs are being triaged, not just whether a version bump shipped.
• Does the notification API let us short-circuit expensive rules, or does it always evaluate everything?

Integration Approach

Stack fit. Unchanged. Composer/PSR-4, framework-agnostic by design; it sits beside Laravel, not inside it. The correct topology is: Laravel Validator at the HTTP boundary (unchanged), selective/validation behind a first-party DomainValidator interface in the application layer for flows that need error accumulation.

Migration path. Unchanged — do not rip and replace. Introduce behind an interface so the implementation is swappable:

1. Define App\Contracts\Validator returning a ValidationResult value object (our own type, not the package's).
2. Implement SelectiveValidator and a LaravelValidator fallback.
3. Pilot in exactly one non-critical flow — a CSV/import pipeline is the canonical case, since per-row error accumulation is where the notification pattern actually earns its keep.
4. Run both implementations in staging and diff outputs before promoting.

Compatibility. Slightly improved by 2.3.0: the PHP 8.5 support means the package is not pinned to an EOL interpreter and is unlikely to block a near-term PHP upgrade. Two caveats remain. First, PHP 8.5 support is upstream-declared, not tested by us — verify against our actual runtime (if we are on 8.2/8.3, this is a non-event; if we plan to move to 8.5, it is a mild de-risk). Second, because the package is framework-agnostic, its PHP-version support says nothing about Laravel compatibility — that burden sits entirely in our adapter, which is another reason to keep vendor types out of application code. Confirm the transitive dependency (likely selective/base) does not collide, and bind the adapter as a singleton in a service provider; no auto-discovery expected. Wrap the package's Notification type at the boundary so nothing outside the adapter imports vendor classes.

Sequencing. Unchanged, with the spike now marginally cheaper since the version-constraint question is partly pre-answered: Spike (½ day) → go/no-go on rule coverage → adapter + contract tests (2–3 days) → pilot in one bounded context → document the "when to use which validator" rule → expand only if the pilot demonstrably beats Laravel's validator on error-accumulation UX. Default outcome if rule coverage is thin remains do not adopt; implement a small in-house notification collector over Laravel's validator instead — same architectural benefit, no dependency risk. Note that 2.3.0 does nothing to improve the odds of surviving the go/no-go gate.

Operational Impact

Maintenance. Unchanged in substance. We own all integration glue and adapter tests. Pin the version exactly (now 2.3.0 or later), commit the lockfile, and add a scheduled check on upstream releases. 2.3.0 argues mildly for the "low-churn, still-alive" characterization — a maintainer shipping a forward-compat release is better than silence — but one release is not a cadence. Budget a nominal recurring cost for dependency review each PHP/Laravel upgrade cycle. If upstream goes quiet, the fork burden is small (validation logic is stable and low-churn) but nonzero.

Support. Unchanged. No commercial backing, no vendor SLA, and a community too small to rely on for answers — troubleshooting means reading source. The contributor credit on 2.3.0 suggests at least occasional outside contribution, which is a weak positive for bus factor but does not change the mitigation: vendor or maintain a fork-ready patch set and record the decision in an ADR.

Scaling. Unchanged and unaffected by this release. Validation itself is CPU-light and not a throughput concern. The one caveat is memory: the notification pattern accumulates every error, so a 100k-row import with systemic failures can balloon the notification payload. Cap batch sizes and fail-fast after an error threshold in import flows.

Failure modes. Unchanged.

• Silent divergence: two validation systems produce different messages/rules for the same field, confusing clients and support.
• Unchecked notification: a caller ignores the result and proceeds with invalid data — enforce a type-level or static-analysis guard so the result must be consumed.
• Missing DB-aware rules: an integrity error surfaces downstream as a 500 instead of a 422. This release does not reduce this risk.
• Upgrade breakage: the package blocks a PHP/Laravel upgrade, forcing an emergency fork mid-cycle. Marginally de-risked for PHP 8.5 specifically; still live for Laravel and for future majors.

Ramp-up. Unchanged. The notification pattern is conceptually simple — a day for a mid-level engineer to be productive. The real cost is cognitive: the team must internalize two validation systems and a documented rule for which applies where. That documentation and the interface boundary are the difference between a contained utility and long-term architectural drift.

Assessment of the 2.3.0 release. A single PHP 8.5 compatibility addition with no rule, API, or Laravel-integration changes. It is a maintenance-signal release, not a capability release: it softens the version-constraint and abandonment concerns at the margin and leaves the decisive objection — thin rule coverage versus Laravel's validator — exactly where it was. The TPM recommendation is therefore unchanged: treat this as a spike-grade dependency, prototype it, measure it against a 50-line in-house collector built on Laravel's validator, and adopt only if it wins decisively on a specific, bounded use case. Re-evaluate if a future release adds DB-aware rules, nested/array error paths, or a maintained Laravel bridge.