- What is selective/validation used for in Laravel?
- Selective Validation is a Laravel-friendly PHP package for applying validation rules only to the fields or contexts you choose. It is useful for partial updates, conditional forms, multi-step wizards, bulk imports, and queue payload validation where you need to accumulate errors instead of validating the entire request payload. It uses a notification pattern that collects errors in an object the caller inspects.
- How do I install selective/validation in a Laravel project?
- Install it with Composer using composer require selective/validation. The package is framework-agnostic and does not ship a Laravel service provider or facade, so there is no auto-discovery bridge to configure. You wire it into your application layer yourself, usually behind a small adapter or interface.
- Does selective/validation work with Laravel form requests?
- It can be used alongside form requests, but it is not a drop-in replacement for Laravel's FormRequest validation. Form requests are tied to the HTTP lifecycle, while selective/validation is designed for application-layer flows that need reusable, field-aware rule sets and accumulated errors. For form request integration you will typically write an adapter that maps its errors to a MessageBag or ValidationException.
- Which Laravel and PHP versions does selective/validation support?
- Version 2.3.0 adds PHP 8.5 compatibility, so the PHP ceiling is not frozen at an older release. The package is framework-agnostic and does not document a Laravel service provider, so check its composer.json constraints for the supported PHP floor and any Laravel-specific requirements before installing. Confirm compatibility against your app's runtime and lockfile.
- Can selective/validation handle partial updates and PATCH requests?
- Yes, that is one of its strongest use cases. You define selective rule sets for the fields present in a partial update and validate only those attributes instead of the full payload. This keeps PATCH endpoints and conditional forms from requiring duplicated rule arrays or scattered checks in controllers.
- Does selective/validation support unique, exists, password, and other Laravel rules?
- Not fully. The package focuses on selected validation rules and does not close the gap for DB-aware rules like unique and exists, password rules, confirmed, implicit rules, localization, or nested array handling. For those cases, keep Laravel's built-in Validator at the HTTP boundary or supplement with custom rules.
- How do I convert selective/validation errors into Laravel ValidationException or MessageBag?
- You need an adapter. The package appends errors to a Notification object rather than throwing or returning a boolean, so map those notification errors into a Laravel MessageBag and throw a ValidationException when you need standard 422 responses, Blade @error output, or Inertia error props. This is typically a small first-party adapter of roughly 100 to 200 lines plus contract tests.
- Is selective/validation a replacement for Laravel's built-in Validator?
- No. Laravel's Validator and FormRequests are still the right choice at the HTTP boundary because they integrate with request validation, implicit rules, localization, and error rendering. Selective Validation fits behind an application-layer interface for flows that need error accumulation across HTTP, console, queue workers, and imports. Use it beside Laravel, not instead of it.
- How should I test selective/validation in a Laravel app?
- Test it through your own adapter or domain validator interface rather than coupling tests directly to the package API. Write contract tests that assert notification errors map correctly to MessageBag keys and ValidationException responses. Include cases for partial payloads, nested fields if you use them, and expensive rules you expect to short-circuit.
- Is selective/validation production-ready and actively maintained?
- Treat it as a high-risk dependency until you verify maintenance and production evidence. The project has modest adoption, limited dependents, and a likely single-maintainer bus factor, and version 2.3.0 is a PHP compatibility release rather than a rule-coverage expansion. If you adopt it, isolate it behind a first-party interface and be prepared to fork or replace it.