Validation Laravel Package

Technical Evaluation

Architecture fit. webman/validation is not itself a Laravel package — it is a Webman plugin that almost certainly wraps illuminate/validation (Laravel's standalone validator component) for Webman's resident-memory, Workerman-based runtime. The fit question is therefore dual: does it deliver Laravel rule semantics outside Laravel, and does it survive a long-lived worker process where Laravel's per-request lifecycle assumptions no longer hold. For a team with deep Laravel validation muscle memory — FormRequests, rule strings like required|string|max:255, custom Rule objects, sometimes, wildcard nested arrays, locale-driven messages — this is the shortest path to keeping that investment if the platform is moving to Webman for throughput. It is a poor fit if the goal is merely "validate input in PHP"; respect/validation or a hand-rolled validator avoids pulling a chunk of the Laravel framework into a stack whose main selling point is a small footprint.

Integration feasibility. Mechanically straightforward: Composer install, register the plugin's service provider in Webman's config, and call Validator::make($request->all(), $rules)->validate(). The real work is not installation but shape-mapping — Laravel's $request->validate(), FormRequest::authorize(), messages(), and attributes() have no direct counterpart and must be reconstructed as middleware, policy checks, and translation arrays. The illuminate/validation dependency drags in illuminate/support, illuminate/translation, illuminate/container, and nesbot/carbon, which must be version-aligned to a single Laravel major (10/11/12); in a monorepo that also runs Laravel services, that constraint can propagate.

Technical risk. High, and driven almost entirely by adoption signals rather than code quality: 1 star, 0 dependents, and an opportunity score of ~46 on a 0–100 scale indicate a package with essentially no production evidence. The webman-php org affiliation is mildly reassuring for continuity, but "first-party" and "battle-tested" are not the same claim. The 2026-02-26 release date suggests it is still moving, which cuts both ways — active maintenance but unproven API stability.

Key questions for the maintainer / spike.

• Which illuminate/validation majors are supported, and is the constraint a caret or a pin?
• Is the validator, translator, and message bag instantiated per-request, or registered as a container singleton that persists across requests in a worker?
• How is locale resolved — per-request from headers, or fixed at worker boot?
• Are custom Rule objects, after callbacks, bail, and wildcard nested keys fully supported?
• What is the exception contract — does a failed validation raise ValidationException, and is there a shipped handler that renders JSON 422 rather than a 500?
• Test coverage and CI matrix (PHP versions, Webman/Workerman versions)?

Integration Approach

Stack fit. Webman on PHP 8.x with Workerman 4/5 and Composer. The package is a natural bridge only in one specific scenario: an existing Laravel codebase (or Laravel-fluent team) evaluating Webman for a high-throughput service where the validation layer is one of several framework touchpoints. Validation alone is a small slice — if the migration also needs Eloquent, queues, events, and auth, those are separate bets with different risk profiles, and this plugin should not be read as evidence the broader migration is cheap.

Migration path. Treat it as a mechanical port, not a rewrite:

1. Lift rules out of FormRequests into standalone rule arrays or dedicated Rule classes that implement Illuminate\Contracts\Validation\ValidationRule.
2. Replace $request->validate() with an explicit Validator::make() call, ideally behind a thin Webman request macro or a ValidatesRequests-style trait so call sites stay terse.
3. Re-implement authorize() as route middleware or policy checks — this is a security boundary and must not be silently dropped during porting.
4. Move messages() / attributes() into translation files keyed by rule and attribute, and confirm the translator actually loads them in the resident worker.
5. Freeze the error payload shape (field → array of messages, HTTP 422) with contract tests so API clients see no behavior change.

Compatibility. Watch for two collision classes: Composer conflicts on illuminate/* versions if Laravel packages coexist in the same dependency graph, and rule-semantics drift if the app previously used topthink/think-validate (similar surface, different edge behavior on nullable/empty strings and numeric coercion). Confirm PHP and Workerman version bounds before committing.

Sequencing. Pin and spike first: install in a sandbox Webman app, port three representative endpoints (one simple scalar ruleset, one nested/wildcard payload, one with a custom Rule and localized messages), and measure worker memory and throughput against a no-validation baseline. Only after the memory/lifecycle behavior is confirmed should the remaining FormRequests be ported in batches, each gated by the contract tests. Budget roughly 1–2 days of ramp-up for a Laravel-fluent engineer plus 1 day for Webman worker-lifecycle specifics.

Operational Impact

Maintenance. This is the dominant cost. One star and zero dependents means no community triage, no Stack Overflow corpus, and effectively a bus factor of one maintained by an org rather than a product team. Plan to own the integration layer outright, vendor or fork the package if it stalls, pin exact versions (no ^ auto-updates in production), and read the diff of every release before bumping. Add a quarterly check on the upstream repo's commit cadence as a kill-switch trigger.

Support. No vendor support path. Escalation is internal: designate one engineer as owner, keep a short internal README documenting the supported rule subset and the exception-handling contract, and maintain the contract tests as the de facto specification. If the service is customer-facing and SLA-bound, the absence of upstream support is a real line item, not a footnote.

Scaling. Resident memory changes the calculus. illuminate/translation and illuminate/support add a few megabytes of baseline per worker, multiplied by the worker count per process manager — usually acceptable, but non-trivial for a stack chosen for its small footprint. The critical scaling concern is state: any singleton validator, shared message bag, or translator whose locale is mutated per-request will leak across requests under concurrency. Load-test with deliberately mixed locales and malformed payloads to force the failure before production does.

Failure modes to instrument.

• Cross-request state leakage (stale error bags, wrong locale) — the highest-severity, hardest-to-reproduce risk.
• ValidationException escaping as an unhandled 500 instead of a 422 — validate the exception handler explicitly.
• Missing translation keys producing raw key strings or fatal errors in user-facing messages.
• Memory growth from Rule objects or after closures capturing request-scoped data and surviving the request.
• Composer lockstep breakage when an unrelated service forces an illuminate/* upgrade.

Ramp-up. Low for anyone who has written Laravel validation; near-zero for rule syntax, a day for Webman's worker/context model and the middleware-based authorization replacement. The hidden cost is not learning the package — it is learning to think in a resident-memory runtime, where "instantiated once" and "instantiated per request" are the difference between a working service and a data-leak incident. Given the adoption signals, the recommendation is to adopt only where Laravel rule parity is a genuine strategic asset, and otherwise prefer a lighter validator with a clearer ownership story.