- How do I install dive-be/laravel-dry-requests in a Laravel app?
- Install it with Composer using composer require dive-be/laravel-dry-requests, then register the service provider and add the package middleware to the routes you want to validate. Because the package is archived, pin the exact version and commit your composer.lock. Pilot it on one low-risk FormRequest route before enabling it more broadly.
- What Laravel and PHP versions does laravel-dry-requests support?
- The last release was in May 2023, so its Composer constraints were written for Laravel and PHP versions available at that time. Check the package's Composer requirements against your current Laravel and PHP versions before adoption. Run a short compatibility spike and test middleware ordering, auth guards, CSRF behavior, and request parsing on your target version.
- How is laravel-dry-requests different from Laravel Precognition?
- Laravel Precognition is the first-party feature for validating requests before executing controller logic, and it covers the same frontend-feedback use case. Dry Requests predates broad Precognition adoption and adds a package-level middleware approach. For new work, evaluate Precognition or a small custom validation endpoint first, and only use this package when you have a specific, time-boxed reason.
- Is dive-be/laravel-dry-requests still maintained?
- No. The repository is archived and the last release was in May 2023, so there are no upstream fixes, security patches, or framework-compatibility guarantees. Your team owns upgrade testing and troubleshooting. Treat it as a short-term utility rather than a strategic dependency.
- Can I safely use dry requests in production?
- Only with care. A dry run still traverses middleware and validation, so auth, authorization, CSRF, session behavior, rate limiting, and validation rules with side effects all matter. Keep it non-production or gated behind a config flag until parity is proven, and never expose a dry-run endpoint publicly without rate limits and authorization.
- How do I test dry-run request validation against normal controller validation?
- Write parity tests that send the same payloads to the dry-run endpoint and the normal controller route, then compare status codes and validation error shapes. Cover valid input, invalid input, authorization failures, file uploads, and environment-dependent rules. Expand route by route only after the results match.
- Why do my dry-run requests return different validation results than real requests?
- Differences usually come from middleware ordering, auth guards, CSRF and session behavior, request parsing, file uploads, or rules that depend on the environment. A dry run may bypass or reorder parts of the normal request lifecycle. Audit the affected route's middleware stack and rule dependencies, and compare responses side by side.
- What are the alternatives to laravel-dry-requests?
- The main alternatives are Laravel Precognition, a custom validation endpoint or middleware that reuses the same FormRequest rules, or forking this package under an internal namespace. Precognition is the preferred first-party option when it fits your client. A minimal custom endpoint is often enough for a single form.
- How do I handle validation rules with side effects in dry requests?
- Dry runs execute the FormRequest rules, so any rule that hits a database, cache, queue, or external service will run during validation. Audit rules for side effects and environment dependencies before enabling dry-run requests. Prefer rules that are pure validators, or separate side-effecting logic out of the FormRequest.
- How do I migrate off laravel-dry-requests to Laravel Precognition?
- Inventory the routes using the package, then replace the dry-request middleware with Precognition or a custom validation endpoint that uses the same FormRequest rules. Add parity tests before and after the swap. Remove the package, update the lockfile, and document the decision and deprecation path.