- How do I install and configure prettus/laravel-validation in a Laravel app?
- Install it with composer require prettus/laravel-validation and confirm the version constraint in composer.json matches your Laravel and PHP versions. The README install snippet incorrectly references prettus/laravel-repository, so do not copy that line verbatim. There is no config file to publish, no migrations, and no middleware; you mainly create validator classes that extend Prettus\Validator\LaravelValidator.
- What is prettus/laravel-validation used for?
- It is a thin validation service layer over Laravel's native validator that moves rule sets out of controllers into dedicated validator classes. It supports separate RULE_CREATE and RULE_UPDATE contexts plus custom error messages and attribute names. It is most useful when validation must run from controllers, repositories, queued jobs, imports, or Artisan commands, not only from HTTP requests.
- How do I define different validation rules for create and update in prettus/laravel-validation?
- Extend Prettus\Validator\LaravelValidator and set a protected $rules array keyed by ValidatorInterface::RULE_CREATE and ValidatorInterface::RULE_UPDATE. Then call with($input)->passesOrFail(ValidatorInterface::RULE_CREATE) or the update context. If you define only flat rules, the same rules apply to both contexts.
- Does prettus/laravel-validation support Laravel 10, 11, 12, and 13?
- Release history spans Laravel 5.4 through 13, and release 1.8.0 claims Laravel 13.x compatibility, but internal assessments conflict on the upper bound. Treat the composer.json constraint plus a CI run on your production Laravel and PHP matrix as the only source of truth. Do not rely on README badges or examples alone.
- How do I use a prettus/laravel-validation validator in a controller or repository?
- Inject or instantiate your validator class, then call with($input)->passesOrFail() with the appropriate rule context. Wrap the call in try/catch for Prettus\Validator\Exceptions\ValidatorException and use getMessages() or the exception's validator to inspect failures. The package throws rather than rendering responses, so your controller or repository owns the error contract.
- Can I use prettus/laravel-validation outside HTTP requests in jobs, imports, or Artisan commands?
- Yes. Because validators are plain classes over Illuminate validation rather than HTTP-bound Form Requests, you can invoke them from queued jobs, CSV importers, Artisan commands, and services. This is the main reason to choose the package over Form Requests when the same rules must run outside HTTP. You still need to handle ValidatorException at each entry point or through a shared helper.
- How do I return JSON 422 validation errors with prettus/laravel-validation?
- The package throws ValidatorException rather than returning a 422 response. Catch it in the controller or register a global renderable handler that converts it to your API error envelope, using getMessages() or the underlying validator errors. Decide one error-envelope strategy before adoption so endpoints stay consistent.
- Does prettus/laravel-validation handle authorization like Laravel Form Requests?
- No. Unlike Form Requests, these validator classes have no authorize() hook, so Gates and Policies must remain a separate explicit check. Do not assume that running a validator gates access to a resource. Keep authorization in middleware, controllers, policies, or Form Requests if you use them.
- Should I use prettus/laravel-validation or Laravel Form Requests?
- Form Requests are simpler for HTTP-only validation and include authorize() for request-level policy checks. This package makes more sense when you need the same rule sets from jobs, imports, commands, or repositories, or when you already use the Prettus repository pattern. Pick one pattern per codebase or document where each is allowed to avoid review inconsistency.
- How do I test and maintain prettus/laravel-validation in production?
- Test validators by instantiating them, calling with($input)->passes() or fails(), and asserting messages for create and update contexts; add feature tests for the 422 envelope at the endpoint. In production, treat it as low code risk but moderate governance risk: one maintainer, low adoption, README drift, and dependency-bump-driven releases. Pin versions, run CI against your Laravel and PHP matrix, and keep fork-and-maintain as the contingency.