Laravel Validation Laravel Package

Technical Evaluation

Architecture fit. Webman runs on workerman with a resident-memory, multi-process model — no per-request bootstrap. webman-tech/laravel-validation is a thin adapter that lifts illuminate/validation (plus its Translator, Container, and PresenceVerifier dependencies) into that runtime. The fit is good when the target is an API service where the team already knows Laravel's rule syntax and the alternative is reimplementing 60+ rules, nested * wildcard validation, conditional rules (sometimes, required_if), and custom Rule objects. It is a poor fit if the project expects anything resembling the Laravel request lifecycle — there are no FormRequests, no middleware-bound validation, no framework-level test helpers.

Integration feasibility. Composer-installable and conventional for the webman-tech/laravel-* family. The real feasibility question is not the plugin itself but the Illuminate dependency web it drags in: illuminate/validation requires illuminate/translation, illuminate/container, illuminate/support, and symfony/http-foundation. Those bring their own PHP version floor (Illuminate 11 requires PHP 8.2) which can collide with a Webman deployment on 8.0/8.1.

Technical risk. Low code surface, high bus factor: 18 stars, 0 dependents, a single-maintainer org, and a low composite score (0.15) that reflects adoption, not quality. The 2025-06-04 release is a liveness signal but not a durability one. Concretely:

• Request shape. Webman's support\Request is not a Symfony Request. Array-based rules work fine off $request->all(); upload rules (image, mimes, file) typically need manual conversion to Symfony\Component\HttpFoundation\File\UploadedFile — a classic gap in these bridges.
• Presence verification. unique and exists need an Illuminate\Contracts\Validation\PresenceVerifier. Without webman-tech/laravel-database (or a hand-written verifier), those rules fail at runtime, not at boot.
• Container mismatch. Laravel's ValidationFactory wants an Illuminate\Container\Container to resolve Rule classes; Webman's DI is PSR-11 but a different contract. Custom rules with constructor dependencies may not receive them.

Key questions for the maintainer/PoC. Which Illuminate versions are in the constraint matrix? Does it ship a PresenceVerifier, or assume laravel-database? How are ValidationExceptions surfaced through Webman's exception handler — 422 JSON, or a raw 500? Are file-upload rules supported? Is there a reusable rule-set/FormRequest abstraction, or just a trait? Is translation config reloaded per worker? Are there tests and a CI matrix in the repo?

Integration Approach

Stack fit. Strongest for greenfield Webman API services and for teams porting Laravel endpoints to Webman for throughput. Weak for anything that needs the full Laravel HTTP kernel.

Prerequisite decision. Pin the whole Illuminate family together. Pair with webman-tech/laravel-translation (messages/i18n) and webman-tech/laravel-database (verifier) so illuminate/* versions resolve consistently; otherwise you own a bespoke PresenceVerifier from day one.

Migration path. Rule definitions and custom Rule classes are copy-paste portable; controllers and FormRequests are not. Extract rules into plain arrays or standalone rule objects before moving, so they survive the framework change.

Compatibility. Pin illuminate/validation to a minor and treat PHP minor upgrades as a re-validation event. Watch symfony/translation and symfony/http-foundation for transitive conflicts with other plugins.

Sequencing.

1. One-day PoC on a single endpoint covering: a nested-array rule set, one custom Rule with a constructor dependency, one unique rule, and one failing request to inspect the error response.
2. Add a boundary exception mapper normalizing ValidationException into your standard error envelope before any second endpoint adopts the package.
3. Adopt for new endpoints only.
4. Backfill existing endpoints once the envelope is stable.
5. Document conventions — notably: no DB queries inside Rule classes, all presence rules go through the verifier.

Exit strategy. Wrap the library behind your own ~100–200 LOC Validator adapter/facade. The package API is small, so this hedge costs a day and makes a swap to raw illuminate/validation or a private fork a one-day change instead of a quarter-long one.

Operational Impact

Maintenance. You effectively co-maintain. Budget 1–2 days per quarter for dependency drift; more if you need file-upload or verifier patches. Fork-and-vendor is a realistic outcome — keep the fork surgical so rebases stay cheap.

Support. No vendor, no SLA. Support is community forum best-effort. Designate one internal owner who is comfortable with Illuminate internals; without that person the package becomes an unowned dependency.

Scaling. Validation itself is stateless and CPU-local — negligible at any worker count. The caveat is unique/exists: each turns a field into a database round-trip, and under Webman's N resident workers that is N× concurrent DB load originating in the validation layer. Cap rule counts per request and avoid pairing presence rules with high-cardinality payloads.

Failure modes to instrument.

• Unhandled ValidationException → 500 instead of 422 (silent API contract break).
• Missing Translator → raw message keys leaking to clients.
• Missing PresenceVerifier → runtime fatal only on the first unique/exists request.
• Container mismatch → custom Rule constructor deps fail at request time, not boot time.
• File rules silently passing or failing on non-Symfony upload objects.
• Resident-memory growth from translator caches and closures accumulating per worker — monitor RSS across restarts.

Ramp-up. Near-zero for Laravel-experienced developers on rule syntax; half a day for explicit validator construction and the error envelope. The real cost is the missing safety net: no artisan, no framework test helpers, no FormRequest conventions — the team must supply those itself, and that is where the schedule risk sits, not in the package.