Laravel Validation Laravel Package

Product Decisions This Supports

• Build vs. buy for request validation: Rather than hand-rolling validation, sanitization, and error-message logic for a Webman service, this package lets the team reuse illuminate/validation — the exact validator that ships with Laravel. That is a "buy" decision with a well-known API surface, which lowers the cost of onboarding PHP engineers already fluent in Laravel.
• API-first / REST roadmap acceleration: Validation is table stakes for any public or partner-facing API. Adopting this lets the team ship endpoints with declarative rules (required, email, unique, nested arrays, custom rule objects) instead of ad-hoc if/filter_var checks scattered across controllers.
• Cross-framework consistency: If the org runs both Laravel services and Webman services, this package standardizes error payloads and validation semantics across them — a meaningful win for shared SDKs, frontend error handling, and API contracts.
• Team staffing and velocity: It narrows the "Webman is unfamiliar" gap. Engineers can apply existing Laravel patterns (rules, messages, custom validators, localization) on day one, reducing ramp-up and review friction.
• Localization and message quality: Built-in translation support and a large catalogue of default messages means better end-user error UX without writing copy per field.

When to Consider This Package

Adopt when:

• You are building on Webman (Workerman-based) and need structured request validation.
• Your team has Laravel experience or existing Laravel rule sets you want to port.
• You need rich, configurable rules, custom rule classes, nested/array validation, and localized messages.
• You want a thin adapter rather than a bespoke validation framework with its own learning curve.

Look elsewhere (or vet carefully) when:

• You are already on Laravel — the validator is built in; this adds nothing.
• You are on Symfony, Slim, or another ecosystem with an established validator (Symfony Validator, Respect/Validation, Rakit) — don't mix idioms.
• You require OpenAPI/JSON-Schema-driven validation or contract-first generation — a schema-based library (e.g., JSON Schema validators) is a better fit.
• You have extreme throughput or minimal-dependency constraints — pulling in an Illuminate component adds weight; a small purpose-built validator may be leaner.
• Project maturity matters to your risk profile: with ~18 stars, zero dependents, and a thin maintainer base, treat this as a low-support dependency. Pin versions, write your own integration tests around it, and have a fallback plan (directly wiring illuminate/validation yourself) before committing to production-critical paths.

How to Pitch It (Stakeholders)

To executives: This is a low-cost enabler for delivering validated, production-grade APIs faster. It lets our PHP engineers reuse the most widely used validation library in the PHP ecosystem (Laravel's) inside our Webman services, cutting custom code and reducing the class of bugs that come from inconsistent input handling. Investment is minimal and the primary risk — a small open-source project — is mitigated by pinning versions and keeping the integration shallow enough to swap out.

To engineering: It's a thin bridge that exposes Laravel's Validator inside Webman so we stop reinventing rule engines per service. You get the familiar rule syntax, custom rule classes, nested array validation, and translation out of the box. Caveats: the project is small (single-digit adoption, no dependents), so we will pin the version, wrap the integration behind our own validation service/facade, and add our own test coverage. If maintenance stalls, the escape hatch is to depend on illuminate/validation directly — the interface we code against stays the same.