Laravel Fluent Validation Laravel Package

Product Decisions This Supports

• Build vs. buy for validation authoring. Building an in-house fluent validation DSL is a recurring "we could knock this out in a sprint" idea. This package is MIT, covers the full native rule surface, and ships an escape hatch (->rule([...])) for anything it doesn't model. Default position should be buy/adopt, not build — unless the runtime baseline rules it out.
• Roadmap sequencing for performance work. The HasFluentRules trait claims up to 160x on nested wildcards and 62x on conditional-heavy payloads, plus batched exists/unique queries. That converts "imports and bulk-edit are slow" from a vague epic into a scoped, one-trait change — worth trialling before committing engineering to custom caching or chunking work.
• Tech-debt / modernization budget. The companion Rector package automates bulk migration of existing string rules. That turns "clean up 200 form requests" from an unbounded estimate into a timeboxed, reviewable migration with a mechanical first pass.
• Quality bar and defect class. Co-locating label(), message(), and fieldMessage() with the rule removes a real source of bugs: messages()/attributes() arrays drifting out of sync with rules(), and mis-ordered unique:users,email,$ignoreId,id arguments. Fewer QA cycles spent on error-copy correctness.
• Onboarding and review velocity. IDE autocompletion and type-scoped methods (FluentRule::string() won't offer digits()) reduce lookup time on a rule API most engineers touch rarely and remember poorly. Measurable through time-to-first-PR and review comment volume on form requests.
• Code-quality gate design. The opt-in PHPStan rules (flagging unbounded each() chains) plus FluentRulesTester and Pest expectations let you set a static-analysis policy for validation, not just a style preference.
• Dependency and platform policy. Requires PHP 8.2+ and Laravel 12+. Adopting it is implicitly a statement that the app stays on a current framework baseline — that should be an explicit decision, not a side effect.

When to Consider This Package

Adopt when most of these hold:

• The app is on Laravel 12+ / PHP 8.2+ and tracks current releases.
• Validation pain is measurable: many form requests, deep wildcard arrays, CSV/JSON import endpoints, bulk-edit screens, settings pages with dozens of fields.
• Engineers already complain about string rules — min:5 ambiguity, Rule::when callables, scattered items.*.name keys.
• The team uses an IDE with completion and already runs PHPStan in CI, so the companion packages land on existing rails.
• You accept a third-party dependency in the request-validation path and can pin a version with a documented exit plan.

Look elsewhere when:

• The runtime is below Laravel 12 / PHP 8.2 — this is a hard blocker, not a soft one.
• The validation surface is small. A few dozen rules across a handful of controllers won't return the migration cost.
• Rules are built dynamically from database or admin config as strings. The fluent API assumes authoring-time structure; you'd be fighting it.
• You need vendor support, an SLA, or a large contributor base. Adoption signals here are thin — roughly 220 stars and zero known dependents — which reads as a single-maintainer project with limited production hardening evidence.
• Validation isn't the bottleneck. If the real complaint is UX of error display or upstream data quality, this package doesn't address it.
• Team bandwidth can't absorb a framework-coupled dependency this quarter. Migration is automatable but not free — Rector output still needs review.

How to Pitch It (Stakeholders)

For executives (2 minutes): This is a low-cost, MIT-licensed developer-experience package for our Laravel validation layer. It makes validation rules typed and self-documenting, which shortens onboarding on a part of the codebase engineers touch rarely, and it removes a class of defects where error messages drift out of sync with the rules. It also claims significant speedups on our heaviest endpoints — bulk imports and multi-item forms. Cost is one engineer, one sprint, on a single module. Risk is a young dependency with a small user base, which we contain by piloting on one module with a pinned version rather than a codebase-wide rollout.

For engineering (5 minutes): FluentRule::string('Title')->required()->min(2)->max(255) replaces string rules, with each type exposing only its valid methods. each() and children() co-locate parent and child rules instead of scattering dot-notation keys. Labels and per-rule messages attach to the rule itself. HasFluentRules on a form request rewrites wildcard expansion as a single tree walk — the README claims up to 160x on nested wildcards — and batches exists/unique into one whereIn. There are companion Rector and PHPStan packages for migration and static enforcement, plus FluentRulesTester for tests. Escape hatch: ->rule([...]) takes any native rule.

Risks to state up front, not bury: small user base and no known dependents; a single maintainer; tight coupling to the Laravel major version; performance numbers are the author's own benchmarks and should be reproduced on our payloads, not taken on faith.

Ask: a one-sprint spike on the highest-volume form request or import endpoint, with three success criteria — a measurable latency improvement on that endpoint, a passing PHPStan run with the companion rules, and one engineer's verdict on authoring ergonomics versus string rules. Decision point at the end of the sprint: expand to a second module or stop and document why.