- How do I install phphd/exceptional-validation in a Laravel application?
- Install it with Composer using composer require phphd/exceptional-validation. Laravel package auto-discovery should register any service provider the package needs. After installation, confirm the package appears in your composer.json and that your application can autoload its classes. No publishing step is typically required unless the package documentation instructs otherwise.
- Which Laravel and PHP versions does exceptional-validation support?
- The package is built around Laravel's native validation layer, so support generally follows the Laravel versions declared in its composer.json. Check the package's Composer constraints before installing to confirm compatibility with your PHP and Laravel versions. If you are on an older Laravel release, verify that the validation exception and rule APIs used by the package are available. Running composer why-not phphd/exceptional-validation can quickly reveal version conflicts.
- How is exceptional validation different from Laravel Form Requests?
- Form Requests are designed for the HTTP layer and are resolved automatically by controllers. Exceptional Validation is intended for services, actions, jobs, and other non-controller layers where no request object exists. It lets you reuse Laravel's rules and messages while throwing a framework-native validation exception when data is invalid.
- How do I validate data inside a service or action class?
- Call the package's validation API with your input data and an array of standard Laravel rules. If the data passes, execution continues normally; if it fails, the package throws a Laravel-compatible validation exception. You can let the exception bubble up to Laravel's exception handler or catch it explicitly in your service layer.
- What exception does it throw and how does Laravel render it?
- It throws a Laravel-compatible validation exception containing the failed rules and messages. In an HTTP context, Laravel's exception handler renders it as a redirect with errors or as a 422 JSON response when the request expects JSON. In console commands, jobs, or other non-HTTP contexts, you should catch the exception and handle the failure explicitly.
- Can I reuse standard Laravel validation rules, custom messages, and attribute names?
- Yes, the package is designed to work with Laravel's familiar validation rules and message system. You can pass custom messages and attribute names just as you would with Validator::make. Custom rule objects and rule strings supported by your Laravel version should continue to work.
- How do I test code that uses exceptional-validation?
- Use PHPUnit or Pest to assert that the expected validation exception is thrown for invalid input. You can also assert on the exception's error messages or violated rules when you need to verify specific failures. For valid input, assert that the service or action completes without throwing. Keeping validation rules in dedicated classes or methods makes these tests easier to reuse.
- Is exceptional-validation safe to use in production?
- The package is small and focused on Laravel's existing validation APIs, so its runtime risk is limited. Before production use, confirm that you are installing a stable tagged release and that its Composer constraints match your PHP and Laravel versions. Run your application's test suite against the exact version you deploy, and avoid floating version ranges for critical validation paths.
- Does it work with Laravel's default exception handler and API responses?
- Yes, because it throws Laravel-compatible validation exceptions, Laravel's default handler can render them as standard validation error responses. API clients typically receive a 422 response with an errors object when the request expects JSON. If you need a different response shape, you can catch the exception in your own handler and transform it.
- How does exceptional-validation compare to calling Validator::make manually?
- Validator::make returns a validator instance, and you must remember to check fails() and handle the failure yourself. Exceptional Validation makes failure explicit by throwing an exception immediately, which prevents invalid data from continuing through your service or action. It keeps controllers thin and makes validation failures part of your domain flow rather than an easily ignored boolean check.