Model Validation Laravel Package

Product Decisions This Supports

• Where validation lives (architecture decision). This package makes "the model is the invariant boundary" a cheap, one-trait option, versus putting rules in FormRequests (request-shaped) or Actions/DTOs (domain-shaped). It's the deciding input for teams that write to the same models from HTTP, queued jobs, console commands, imports, and admin panels, and are currently duplicating rules per entry point.
• Build vs. buy. Buy. The alternative is a bespoke trait plus your own test coverage; this gives you a maintained implementation with configurable validationRules/validationMessages/validationAttributes and validationData/beforeValidation/afterValidation hooks, for effectively zero cost.
• New use cases unlocked by v2 (feature decision). skipValidation(), saveWithoutValidation(), and exception-safe Model::withoutValidation(fn () => ...) remove the package's biggest historical objection — the inability to bypass validation. This makes it viable for seeders/fixtures, legacy data imports, backfills, admin "force save" flows, and test factories, which previously forced teams to raw DB writes or to skip the package entirely.
• Upgrade planning (roadmap forcing function). v2 requires PHP 8.2+ and Laravel 12+, drops Laravel 11 and earlier, and swaps laravel/framework for individual illuminate/* components. If a Laravel 12/13 upgrade is already on the roadmap, this aligns cleanly; if you're on Laravel ≤11 or PHP ≤8.1, v2.0.0 is a hard blocker and you stay pinned to 1.x (confirm whether 1.x is still maintained).
• API-shape decision. validate() now returns the validated data array. That makes the model validator usable as the single source of a validated payload (feeding a DTO, event, or downstream job), but it is a behavior change to audit against existing callers.
• Testing/quality signal for vendor risk. A 20-test PHPUnit + Orchestra Testbench suite, a PHP 8.2–8.4 × Laravel 12–13 CI matrix, Pint style checks, and community health files materially improve the "is this safe to depend on" answer versus an untested single-maintainer package.

When to Consider This Package

Consider adopting when:

• Multiple write paths touch the same models and validation rules are genuinely model-scoped invariants (required fields, formats, cross-field consistency) — not request concerns like authorization, rate limiting, or uploads.
• You are on Laravel 12/13 and PHP 8.2+ (hard floor for v2).
• You need conditional bypass: seeding, imports, backfills, migrations of dirty data, admin overrides. This is the new capability and the main reason to revisit the package now.
• You want a minimal-footprint dependency: a trait and config properties, no migrations, no schema changes, no service-provider machinery.
• You want the underlying Illuminate\Validation\Validator for edge cases (modelValidator() / ModelValidator::makeValidator()) and an validateOnUpdating() hook alongside the existing saving/creating hooks.

Look elsewhere or proceed with caution when:

• Your architecture deliberately keeps models persistence-only (hexagonal / Actions + DTOs). Model-layer validation fights that grain; use FormRequests or Action-level validation instead.
• You are on Laravel ≤11 or PHP ≤8.1 — v2.0.0 will not install. Verify 1.x support status before relying on it.
• Validation must be tied to request context, authorization, or per-user policy — that belongs in FormRequests/Gates.
• You write primarily via bulk query-builder paths (insert, upsert, mass update). Model event-driven validation does not cover those; the package cannot be your integrity guarantee there.
• Per-save validation cost is unacceptable on hot write paths; validate at the boundary instead, or adopt only with deliberate withoutValidation() usage.
• You need contractual guarantees: this is a single-maintainer OSS package with no stated LTS or security policy. The new tests and CI are a good signal, not a support contract — keep your own thin integration tests and treat it as swappable.

Migration notes for the decision record: environment bump (PHP 8.2 / Laravel 12+) is the real cost; the models' public API is unchanged (trait name, validate(), validateOnSaving()/validateOnCreating(), config properties, hooks). Audit callers that consumed validate()'s old return value, and re-check Composer resolution now that the package requires individual illuminate/* components rather than laravel/framework.

How to Pitch It (Stakeholders)

For executives: "A small, free open-source component that lets us declare validation rules once, on the data model, so every path that writes that data — web forms, background jobs, imports, admin tools — enforces the same rules. The v2 release brings it current with Laravel 12/13 and PHP 8.2, adds an automated test suite and CI, and adds an explicit 'skip validation' switch we need for data imports and backfills. Cost is essentially zero and it removes duplicated rule-writing. The residual risk is that it's a single-maintainer package with no formal support policy — mitigated by keeping our own thin integration tests and treating the dependency as swappable."

For engineering: "Existing model APIs are unchanged — trait, validate(), validateOnSaving()/validateOnCreating(), the rules/messages/attributes config, and the validation hooks all behave as before. What changes: baseline is PHP 8.2 / Laravel 12+, the package now depends on individual illuminate/* components instead of laravel/framework, and validate() returns the validated data array instead of a boolean — grep for callers. The win is skipValidation(), saveWithoutValidation(), and exception-safe Model::withoutValidation(fn () => ...), which finally lets us seed, import, and backfill without fighting validation; plus validateOnUpdating() and a modelValidator() accessor when we need the underlying validator. Design constraint to respect: validation fires on Eloquent model events, so insert/upsert/mass update query-builder calls bypass it — any integrity guarantee must cover those paths explicitly."