Laravel Dry Requests Laravel Package

Product Decisions This Supports

• Form UX and conversion work: This package enables "dry run" validation — a client can ask the server whether a request would pass validation without triggering the controller action or any side effects. That directly supports inline, keystroke-level form feedback (e.g., "email already taken," "username available," "password too weak") as a product feature rather than a nice-to-have.
• Feature scoping for form-heavy surfaces: Sign-up, onboarding, checkout, account settings, and any multi-step wizard are the highest-leverage use cases. If a quarter's roadmap is dominated by these flows, this pattern earns its place; if not, it's a distraction.
• Build vs. buy (or "build vs. borrow"): Given the archived status, the right framing is reference implementation, not dependency. The PM decision is usually "should we adopt this pattern in-house?" — and the answer is often yes, because the concept is small and the package is no longer maintained.
• Reducing duplication across dozens of forms: When many endpoints need the same "validate-only" behavior, standardizing on one approach (whether this package or an internal fork) lowers engineering cost and keeps validation rules in one place — the FormRequest — instead of reimplementing per-feature.
• Roadmap sequencing: Adopting the pattern is cheap and can be scoped into existing form work; adopting the package as a long-term dependency should not be scheduled without a maintenance owner.

When to Consider This Package

Consider it when:

• You are on a Laravel version the package actually supports and can pin/verify that compatibility.
• You have a large, ongoing surface of forms where per-field server validation is a real product requirement, and centralizing it in FormRequests (rather than bespoke per-endpoint validation) is a clear win.
• You are willing to treat it as a starting point: fork it, vendor it, or reimplement the small amount of logic internally so you are not exposed to an unmaintained dependency.
• You want a fast, low-effort proof-of-concept to demonstrate the UX benefit before committing engineering time.

Look elsewhere (or build it yourself) when:

• You need active maintenance, security patching, or guaranteed compatibility with current/future Laravel releases — the repository is archived and the last release was May 2023. For anything safety- or compliance-relevant, this is disqualifying as a direct dependency.
• The underlying capability is already available natively in your Laravel version — verify first; reimplementing a small validation endpoint is often less work than governing a stale package.
• Your validation surface is small or one-off; the coordination overhead exceeds the benefit.
• Your team has strong opinions on validation architecture and would rather own the code outright.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost enabler for better forms — the kind of thing that measurably improves sign-up and checkout completion by giving users instant, server-accurate feedback as they type, instead of waiting until submit to discover a problem. The pattern is valuable and cheap to adopt. The package itself is archived (last release 2023, MIT licensed), so the recommendation is to adopt the approach and own a small piece of code rather than take on an unmaintained dependency. Net: high UX upside, negligible incremental cost, manageable risk if we keep ownership in-house.

For engineering: dive-be/laravel-dry-requests lets a client probe a FormRequest for validation results without executing the controller — clean, side-effect-free, and a natural fit for async field validation. It's ~200 stars, MIT, and archived, so treat it as a reference implementation: fork it or reimplement the thin layer internally, pin Laravel compatibility, and add it to the maintenance backlog. Validate whether current Laravel already covers this before writing code.