- How do I install and use theriddleofenigma/laravel-model-validation?
- Install it with composer require theriddleofenigma/laravel-model-validation. Add the Enigma\ValidatorTrait to your Eloquent model, declare a public $validationRules array, and register the event you want to validate on inside the model's boot method, for example static::validateOnSaving(). After that, any invalid save throws Illuminate\Validation\ValidationException, just like Laravel's native validator.
- Which Laravel and PHP versions does laravel-model-validation support?
- The package targets Laravel 12.x and 13.x only, and requires PHP 8.2, 8.3, or 8.4. Laravel 13 additionally requires PHP 8.3 or newer, and end-of-life Laravel releases are explicitly not supported. Confirm your application is already on a current stack before adding the dependency, since there is no backward compatibility with Laravel 10 or 11.
- Can I validate only on create or only on update instead of every save?
- Yes. The package ships three helpers that register the corresponding Eloquent event listener: validateOnSaving, validateOnCreating, and validateOnUpdating. Use validateOnSaving when you want both create and update covered, or pick the more specific helper when rules differ between insert and update scenarios.
- Does model validation run for mass updates like Model::where(...)->update()?
- No. Eloquent model events do not fire for query-builder writes such as Model::where(...)->update(), upsert, insert, raw SQL, or saveQuietly(), so those paths bypass validation entirely. This means the rules are advisory rather than a true data invariant, and any teammate who assumes the model always validates is one mass update away from invalid data. Pair the package with database constraints for anything that actually matters.
- What happens when validation fails inside a queue job or an artisan command?
- Invalid saves throw Illuminate\Validation\ValidationException, the same exception Laravel uses for HTTP validation, which normally triggers a redirect with flashed errors. In a queue worker or console command there is no request to redirect, so you must catch and handle that exception explicitly in those entry points. Verify the behavior in your own jobs before relying on the package for background writes.
- Is laravel-model-validation a replacement for Form Requests?
- It can replace them, but you should generally pick one source of truth rather than running both. Form Requests keep validation at the HTTP boundary, while this package centralizes rules on the model so they travel with it across HTTP, queues, console commands, and admin panels. Form Requests still make more sense for request-shaped concerns like authorization and input normalization, and running both risks duplicated or drifting rules.
- How are unique rules handled on update, and will an existing record fail its own uniqueness check?
- The documentation excerpt does not document ignore-on-update semantics for the unique rule, so treat this as something to verify before adopting. If the validator runs against the full model without excluding the current primary key, every save of an existing record could fail uniqueness. Write a test that updates an existing model with a unique rule and inspect whether the package passes the model's own key as the ignore ID.
- Are conditional rules like sometimes and required_if, nested array rules, and custom Rule objects supported?
- Because validation is delegated to Laravel's own validator, standard rule strings including conditional rules such as sometimes and required_if should work as they normally do. Custom Rule objects and nested array rules are also likely supported for the same reason, but the package README does not spell out attribute-name or custom-message customization, so test those cases explicitly. If you need publishable language files or attribute aliases, confirm the behavior in a branch before depending on it.
- Is there an escape hatch to skip validation for a specific save?
- Any write that bypasses Eloquent model events also bypasses validation, so saveQuietly() on the model and query-builder updates will not run the rules. That gives you an implicit escape hatch for seeding, fixtures, and data migrations, but it is not a substitute for a documented shouldValidate-style hook. Check the source or issue tracker to confirm whether a per-model opt-out method exists and is documented.
- Is this package mature enough for production use?
- The project is a single-maintainer package with roughly 33 stars, no dependents, and a CI test badge, so there is limited third-party signal that it will survive future Laravel major releases. Treat it as a trial rather than an immediate standard: pin the version, review the test suite and issue tracker activity, and introduce it on one low-risk internal model first. It fits greenfield or actively modernized Laravel 12 and 13 applications with multiple write paths, not legacy estates standardized on Form Requests.