Validation Laravel Package

Product Decisions This Supports

• Architecture: rules-on-the-object vs. rules-in-the-request. The package remains a cheap proof-of-concept for attribute/annotation-based validation on DTOs and domain objects, as an alternative to Laravel's array-of-rules style in FormRequests. 2.0.0 does not change the ergonomics hypothesis — it only modernizes the underlying binding (Symfony 6, typed method signatures). You can still test "is colocating constraints with the data shape worth deviating from framework idiom?" in an afternoon.
• Build vs. buy vs. do nothing on internal validation conventions. Still a reference implementation for the ~40-line in-house glue option rather than a dependency candidate. The 2.0.0 release materially changes the cost side of that equation: the maintainer is active (breaking the "abandoned since mid-2023" read), but the release makes classes final and adds native parameter types, which means the fork-and-trim path is now fork-and-edit — you can no longer subclass Validator to adapt it. Re-estimate the glue option as "copy the useful subset" rather than "extend the package."
• Feature scoping for a validation-adjacent roadmap item. Unchanged: if a ticket says "improve validation consistency across services," this is evidence the problem is real and the solution space is crowded — it argues for a convention doc, not a new package.
• A "do not adopt" recommendation is still the deliverable — but for different reasons. The prior rationale ("no maintainer activity in ~2 years, no downstream users") no longer holds for maintenance activity. The remaining rationale is: no observable adoption (stars/dependents were not provided in this review round and should be re-checked), single-maintainer bus factor, and a breaking major release with no documented deprecation path, which means consumers carry a version-pinning obligation. Treat the repo as a maintained pattern sample, not a supported dependency.

When to Consider This Package

Consider only if: you are on PHP 8.1+ and Symfony Validator 6 (2.0.0's floor), you want a thinner binding layer over symfony/validator, you are comfortable with final classes and composition over inheritance, and your team accepts single-maintainer risk with an explicit fork-or-fix posture. Validation must run outside the HTTP layer today.

Look elsewhere if any of these are true (realistically, most of them still are):

• You are pinned to Symfony Validator 5 or PHP < 8.1 — 2.0.0 hard-drops that range, and the 1.x line is now a dead-end branch with no patch path.
• Your spike subclassed Validator or its collaborators — classes are final and method signatures are now natively typed, so that code breaks on upgrade and cannot be re-extended.
• Validation is security-adjacent (auth input, payment data, PII) — a single-maintainer wrapper still has no organizational CVE response path you can rely on contractually.
• You are standardizing across multiple services or teams — a single-vendor package with no demonstrated downstream users remains a coordination liability, and a breaking 2.0 increases version-skew risk across services.
• You want DTOs plus validation plus casting plus typed construction — spatie/laravel-data is actively maintained, has real adoption, and publishes upgrade guides.
• You just need request validation — Laravel's native Validator and FormRequests are already the answer.

Before committing to any spike or upgrade, verify: whether Laravel 11/12 compatibility is actually exercised in CI (the release notes list tooling bumps — PHPStan, PHP-CS-Fixer — but no framework-version testing evidence); which exact Symfony 6 minor is required; whether a documented 1.x → 2.0 deprecation cycle existed or whether this was a hard break; and current star/dependent counts, since the prior assessment's "zero dependents" claim was not re-verified in this round.

How to Pitch It (Stakeholders)

To executives: "We re-reviewed the attribute-based validation package after its 2.0.0 release. Correcting our earlier read: the maintainer is active — they shipped a modernized version on Symfony 6 with upgraded static analysis and coding-standard tooling. That removes the 'abandoned' objection but not the core risk: it is still one maintainer, with no evidence of production users, and 2.0.0 is a breaking release that locks us to Symfony 6 / PHP 8.1+ and removes the extension points we'd need to customize it. Estimated cost of adoption is unchanged in kind — a fork we'd own — plus an ongoing version-pinning obligation. I still recommend an actively maintained alternative or the ~40-line binding we write and own ourselves; the package is now a better reference than before, not a better dependency."

To engineering: "2.0.0 requires Symfony 6, makes the classes final, and adds native parameter types to validate, validateProperty, validatePropertyValue, getMetadataFor, and hasMetadataFor. The typed signatures are a genuine readability win, but final plus typed params means you can't subclass or override the Validator anymore — adaptation now means editing a fork, not extending it. That's fine if we're copying the pattern into our own service provider; it's a problem if we were planning to consume the package and wrap it. It also means any spike code written against 1.x won't survive the upgrade intact. If we still want this capability, reproduce the useful subset in a service provider we own deliberately — that's cheaper than inheriting a package we'd have to read line by line and pin to a Symfony major anyway."