Hydrator Validator Laravel Package

Product Decisions This Supports

• Contract-first ingestion at non-HTTP boundaries. The package's actual wedge is hydrating and validating raw arrays in one step — webhook receivers, queue message consumers, CSV/bulk importers, partner sync jobs. Today that logic usually gets hand-rolled as a mapper class plus a Validator::make() call, duplicated per payload type. This collapses it into a single self-validating DTO.
• Typed internal service boundaries. Replacing associative arrays with readonly, typed objects between controller → job → service layers. This is a code-health/defect-rate play (type errors surface at hydration instead of three call frames later), not a feature play.
• A build-vs-buy decision on validation plumbing, not on validation itself. Validation already exists in any Laravel stack. The decision this informs is where it lives: framework FormRequest vs. validation intrinsic to the DTO. That's an architecture standard, and it's the decision worth making deliberately rather than by accretion.
• Roadmap input for ingestion-heavy work. If the next two quarters include partner API onboarding, event-driven ingestion, or data migration tooling, this pattern is directly relevant. If the roadmap is CRUD screens, it's not.
• Explicitly not supported: standard Laravel HTTP request validation. Adopting this there would create a second validation dialect alongside Illuminate\Validation — two rule vocabularies, two error shapes, two things to teach new hires.

When to Consider This Package

Consider it when:

• You're on Yii3 or a deliberately framework-agnostic PSR-centric service, and you want one object that both hydrates and validates.
• Validation genuinely belongs to the value object (a self-validating DTO), not to a controller-adjacent class.
• The data enters outside Laravel's HTTP layer, so FormRequest isn't available anyway.
• You're prepared to own the integration: mapping yiisoft validator errors into your API error envelope, and writing the docs your team will actually read.
• Maintenance signals are adequate for a small, well-scoped utility: BSD-3-Clause, current release cadence (Dec 2025), but ~14 stars and a single-vendor ecosystem.

Look elsewhere when:

• You are a Laravel shop. spatie/laravel-data delivers hydration + validation + request integration with a large community, and it's what your engineers already reach for. Default answer.
• You need Laravel rule parity (exists, unique, password, custom rule objects). Yiisoft's rules won't match; you'll maintain two vocabularies forever.
• You need ecosystem depth. 14 stars means effectively zero third-party tutorials, Stack Overflow coverage, or community bug-fixing. Every edge case is yours to solve.
• Dependency footprint matters. Shipping a parallel validator stack next to Illuminate\Validation is real weight for a marginal gain.
• You need vendor SLAs or a hiring pool. Neither exists here.

How to Pitch It (Stakeholders)

Executives. This is a small, correctly-scoped utility that does not unlock a new capability — we already validate input. The recommendation is not to adopt it as a standard. The downside of a wrong call isn't an outage; it's quietly accumulating a second validation system that costs us maintenance and onboarding time for years. Revisit only if we deliberately move ingestion logic off the framework's HTTP layer, at which point it becomes a reasonable candidate. Low cost to evaluate, real cost to adopt casually.

Engineering. The honest pitch: it solves "hydrate then validate" in one step for data arriving outside HTTP — jobs, webhooks, imports. That's a real papercut. But if we want that pattern, spatie/laravel-data is the lower-friction answer and keeps us in the ecosystem we hire for and debug in. yiisoft/hydrator-validator is competently built (BSD-3, actively released) and would be my pick if we were prototyping a framework-agnostic ingestion service or evaluating Yii3 — with the caveat that we write the Laravel bridge, the docs, and the error-mapping layer.

Decision requested:

1. Confirm we will not standardize on a second validation dialect inside the Laravel app.
2. If the "self-validating DTO at the ingestion boundary" pattern is worth pursuing, sponsor a one-week spike comparing spatie/laravel-data against this package for a single real webhook/import payload. Exit criteria: Laravel rule parity, error-envelope fit, and time-to-first-working-DTO for an engineer who has never seen either library.