Schema Validator Laravel Package

Product Decisions This Supports

• Validation architecture: where rules live. The package's core proposition — define a schema once, reuse it across form requests, API endpoints, and console commands — is a real architectural decision. Adopting it (or its pattern) means committing to a dedicated validation layer instead of inline $request->validate() calls scattered across controllers.
• Build vs. buy for request-to-DTO mapping. This is the decision the package actually forces. Laravel ships validation but not clean DTO hydration from validated input; this package bundles both. The PM question is whether that gap is worth an external dependency, a thin in-house adapter, or an established alternative.
• API contract consistency. If public or partner-facing APIs are on the roadmap, a declarative schema layer directly supports consistent error messages, versioned payload contracts, and generated documentation. That is a product-quality lever, not just an engineering one.
• Roadmap scoping for a validation refactor. If adopted, "consolidate validation rules" becomes a funded workstream with an owner and a migration plan. If rejected, it should be explicitly closed rather than re-litigated each quarter.
• Primary use cases: form requests with nested/array payloads, API request validation, artisan command input, and any place where the same rules are currently duplicated across HTTP and CLI entry points.
• Status decision (the deciding factor). This is archived, at 0.0.1 (single release, Aug 2021), 5 stars, with a metadata/description mismatch — the package listing says "for Symfony" while the documentation describes a Laravel package. That inconsistency alone is a due-diligence red flag: we cannot reliably tell what the artifact actually is. The realistic decision is "harvest the pattern, do not adopt the dependency."

When to Consider This Package

Consider only as a design reference, not a dependency. The concept — declarative schema definitions reused across HTTP, API, and CLI, with nested/array support and custom messages — is worth reading and copying into an internal implementation. The code itself does not clear the bar.

Adoption criteria it fails:

• Maintenance: archived, no releases since 2021. No path to a security or compatibility patch.
• Maturity: 0.0.1 is pre-SemVer-stable by definition; there is no upgrade history, no deprecation surface, and no community battle-testing.
• Signal: 5 stars and a low assessment score mean effectively no third-party usage to learn from; failure modes will be ours alone to discover.
• Verification: no evidence of a test suite or CI. We would be validating the dependency ourselves.
• Framework fit: a 2021 package almost certainly pins older illuminate/* constraints, which will block a Laravel 10/11 upgrade — a cost that lands months later, on a different team.
• Identity ambiguity: the Symfony-vs-Laravel description conflict must be resolved before any technical evaluation is even meaningful.

When to look elsewhere:

• Any production dependency. Use Laravel's native validator and form requests; add spatie/laravel-data for DTO hydration if that is the actual gap. Both are maintained and carry upgrade paths.
• Any code path with security, compliance, or audit exposure where unpatched validation logic is a liability.
• Any team that needs vendor support or an upgrade guarantee.

The narrow case where it could squeak by: a time-boxed spike to evaluate the developer experience of schema-driven validation, in a disposable or air-gapped internal tool, with the explicit understanding that nothing ships to production on it. Even then, MIT licensing means forking and owning it is the only defensible long-term form — which raises the real question of why we wouldn't just write the ~100-line equivalent ourselves.

How to Pitch It (Stakeholders)

To executives (one paragraph): A small open-source package promises to let one schema definition validate form submissions, API payloads, and console commands consistently. The idea is sound and maps to a real duplication problem in our validation code. The package itself is not adoptable: it is archived, has had exactly one release (2021, version 0.0.1), has negligible adoption, and its own listing contradicts its documentation. There is no maintenance or security-patch path. Recommendation: do not add it as a dependency; instead fund a short internal effort to implement the pattern ourselves or standardize on a maintained alternative. Cost of the recommendation is roughly an engineer-week; cost of the alternative is inheriting an unmaintained validation layer we cannot patch.

To engineering (the ask):

• Do not composer require this. It is archived at 0.0.1, single-release, pre-stable, with an unresolved Symfony/Laravel identity conflict in its metadata.
• Do steal the pattern. A declarative schema layer, reused across form requests, API controllers, and artisan commands, with DTO hydration at the boundary, is the right shape. Implement it behind our own interface (App\Contracts\...) so the underlying mechanism stays swappable — that wrapper is cheap insurance regardless of what we pick.
• Prefer the maintained options first: native Laravel validation + form requests for rules; spatie/laravel-data if clean DTO mapping is the actual gap. Both have upgrade paths and active maintenance.
• If someone still wants to try it: timebox to a one-day spike behind a config flag, single code path, MIT-fork if it survives — and pin the exact version and commit the lockfile.
• Deliverable: a one-page decision record — adopt / build / buy — with the validation-layer owner named, so this does not resurface.