- How do I install and use model validation in a Laravel app?
- Run composer require kumaravelk011/model-validation, then add the ValidatorTrait to each Eloquent model you want protected. Define a $validationRules array, with optional $validationMessages and $validationAttributes, and the trait validates attributes automatically on the saving, creating and updating events. No service provider, config file or facade is required. The package needs PHP 8.2 or higher and Laravel 12 or higher.
- Does this package support Laravel 10 or 11?
- No. Version 2.x targets PHP 8.2+ and Laravel 12+, and older framework versions are left on an unmaintained 1.6 branch rather than a maintained version pin. If your service is still on Laravel 10 or 11, staying there means forking or planning an upgrade rather than just holding a version. Laravel 13 appears in the test matrix but should be treated as forward-looking until it is confirmed generally available, so pin a stable framework release in production.
- How is model validation different from Laravel Form Requests?
- Form Requests only run inside HTTP controllers, so writes from queue jobs, artisan commands, seeders, imports and scheduled tasks never reach them. This package runs the same Laravel validator at the persistence boundary, so model-defined rules apply wherever Eloquent saves a record. Many teams keep Form Requests for request-shaped input and use model validation as the final guard for domain invariants.
- What happens when validation fails?
- The trait throws Illuminate\Validation\ValidationException, the same exception Form Requests throw, so existing exception handling and JSON error responses keep working. In version 2.x, validate() returns the validated data array rather than a boolean, so avoid writing if ($model->validate()); a non-empty array is truthy and an empty one is not, which can silently change behaviour. Call validate() to get the data back and rely on the exception for failures.
- How do I skip validation during bulk imports or seeding?
- Version 2.x adds skipValidation(), saveWithoutValidation() and withoutValidation() so fixtures and imports can bypass the trait without disabling it globally. withoutValidation() wraps the work in a try/finally that restores the flag even when an exception is thrown. If you run under Laravel Octane, confirm the disabled flag is not held in static state that could leak between requests in a long-lived worker.
- Are unique rules automatically scoped to ignore the current model on update?
- This is not addressed in the package notes, so assume you must handle it yourself. Use Rule::unique('users')->ignore($this->getKey()) in the rule definition, or apply a separate rule set on update. Unscoped unique rules are the classic failure mode for validation traits that run on the updating event, because a record will conflict with its own existing row.
- Does it validate updateOrCreate, firstOrCreate, upsert, saveMany and relationship saves?
- The trait hooks the standard Eloquent saving, creating and updating events, so anything firing those events is validated: save(), updateOrCreate(), firstOrCreate(), relationship create() and save(), and the per-model loop in saveMany(). Operations that bypass model events, such as upsert() and saveQuietly(), are not validated and will write unvalidated data. The package does not document every path explicitly, so test the specific flows your application relies on.
- Do I need to register a service provider or publish config for this package?
- No. The package is a thin trait with no service provider, config file or facade, so there is nothing to register or publish. You add the trait to a model, define the rules, and validation starts on the next save. That low coupling also makes it easy to remove later if you move validation into observers or a dedicated domain layer.
- Is the package production ready and well tested?
- The v2.0.0 baseline has around 20 tests across PHP 8.2 to 8.4 and Laravel 12 to 13, which is a credible floor but small for code that hooks model events. The risky cases are interactions: nested saves, updateOrCreate, upsert, relationships, saveQuietly and the exception paths in withoutValidation(). Add your own tests around the paths you depend on, and check the repository for a stated maintenance commitment and co-maintainers before adopting it in a critical service.
- What alternatives should I consider instead of a model validation package?
- Laravel Form Requests remain the default for HTTP input, and model observers or a custom base model can enforce invariants without an extra dependency. You can also validate in mutators, casts or a dedicated DTO and action layer before touching Eloquent. This package is worth it when you want rules colocated with the model and enforced for jobs, commands and seeders as well as web requests.