Validator Laravel Package

Product Decisions This Supports

• Build vs. buy for a validation layer. This package is best framed as a reference implementation, not a product you adopt. It maps to the decision "should we keep Laravel's built-in Validator/FormRequest, or invest in a framework-agnostic constraint engine like Symfony's?" — and it gives engineering a concrete artifact to read while answering that question.
• Architecture and coupling strategy. If a roadmap item involves extracting validation out of HTTP-layer FormRequest objects into domain-layer value objects, DTOs, or standalone services, toa/validator is a design pattern worth skimming (constraint objects, metadata-driven validation) before committing to a homegrown approach.
• Portability / multi-framework roadmap. Relevant only if there is a real, funded need to validate data outside a Laravel runtime (CLI tools, workers, non-Laravel services in a polyglot stack). Its Symfony inspiration is the interesting part; its own implementation is not a differentiator.
• Dependency-risk policy calibration. With 0 stars, 0 dependents, and a near-zero health score, it is a useful negative case for whatever adoption criteria your team applies to third-party packages. It can help standardize what "acceptable dependency" means.
• What it should not drive: feature roadmap commitments, SLA expectations, or any decision where you need a maintained upstream. There is no observable community, release cadence, or downstream usage to anchor a bet on.

When to Consider This Package

Consider it only when:

• You are already inside the toa framework ecosystem and the package is designed to be consumed there.
• You have a Symfony-Validator-shaped requirement (constraint objects, attribute/annotation-style rules, metadata-driven validation) and cannot or will not pull in symfony/validator itself.
• You are evaluating patterns, not shipping code — a time-boxed read, or a spike, rather than a production dependency.
• You have engineering capacity to fork, vendor, and own the code indefinitely, including security patches and compatibility with future Laravel/PHP versions.

Look elsewhere when:

• Standard Laravel validation needs → use the framework's built-in Validator, FormRequest, Rule objects, and after() hooks. This is the default and should be beaten on merit, not novelty.
• Genuine Symfony-style constraints with an actual support contract → symfony/validator, which has years of maintenance, security handling, and documentation behind it.
• Standalone rule engines / fluent DSLs → respect/validation (low-coupling, framework-independent), or Laravel Rule objects if you want to stay native.
• Any production path with a security or compliance surface — input validation is security-adjacent; a package with no dependents and no visible community gives you no way to learn about vulnerabilities or breaking changes except by reading commits yourself.
• You need answers. Zero stars and zero dependents means zero Stack Overflow coverage, zero blog posts, zero third-party integration examples. Support cost is entirely internal, and that is a cost even at $0 license.

Hard red flags to log explicitly: unknown Laravel/PHP version compatibility, no evidence of a release/versioning policy, single-maintainer risk, and an MIT license that lets you fork but does not obligate anyone to keep it alive.

How to Pitch It (Stakeholders)

To executives: This is not a vendor or dependency recommendation. It is a free, MIT-licensed validator component inspired by Symfony's, with essentially no adoption — zero stars, zero dependent projects, no community. The financial risk of adoption is zero in license fees and non-trivial in engineering ownership: if it breaks or goes unmaintained, we fix it ourselves. Recommendation: treat it as a 1–2 day design spike by a single engineer to inform our validation-architecture decision, not as a roadmap item or a line item in composer.json. The spike has a clear decision gate and a cheap exit.

To engineering: Read it for the Symfony-style constraint/metadata pattern if we're considering moving validation off FormRequest and into domain objects. Do not add it as a production dependency. If the spike concludes we want this shape, the recommendation is one of: (a) stay on Laravel's native validator with Rule objects, (b) adopt symfony/validator, or (c) fork this and accept explicit ownership — with (a) as the default and (b) preferred over (c) unless there's a specific reason to avoid Symfony. Either way, we document the decision and the criteria we used, so the next team doesn't re-litigate it.

The ask: one engineer, one to two days, one written recommendation. Deliverable is an ADR (architecture decision record) on our validation approach — not a merged pull request.