Request Dto Resolver Laravel Package

Product Decisions This Supports

• API contract standardization (build vs. buy): The core decision this artifact informs is whether request payloads enter the domain as typed DTOs or as untyped arrays ($request->all()). That is an architecture standard, not a feature, and it is cheap to adopt and expensive to retrofit later. Treat this repo as a reference implementation for that standard, not as a dependency to install.
• Engineering velocity on new endpoints: Every endpoint that can declare a typed request object removes a validation/parsing layer from the controller. That shows up as reduced per-endpoint effort in sprint estimates and lower defect rates on malformed-payload handling — both measurable if you baseline before/after.
• Stack selection input: This is a Symfony bundle, not a Laravel package. For a Laravel roadmap it does not support a feature decision; it supports a platform decision (if you are evaluating Symfony, this is evidence the ecosystem has this ergonomic available).
• Use cases where the pattern pays off: internal/partner APIs with published contracts, webhook receivers (third-party payload shape is effectively your schema), and any endpoint with >5 input fields where controllers otherwise accumulate ad-hoc Validator::make() calls.
• Roadmap framing: position as a code-standard initiative ("typed request boundaries") with a small, contained scope, rather than as an infrastructure bet. Opportunity score of 47.3 and 1 star / 0 dependents mean it should not appear on a roadmap as a dependency upgrade line item.

When to Consider This Package

Consider it (or its pattern) when:

• You are on Symfony 6/7 and want controller-argument DTO hydration via an attribute, with the resolver registered as a bundle.
• The surface area is small enough to audit: read every file in an afternoon, then vendor or fork it into your monorepo so no unreviewed upstream change can reach production.
• You need the pattern, not the package — a controller argument resolver is roughly a service provider binding plus one resolver class. For Laravel, the equivalent 40-line implementation is likely cheaper than evaluating a Symfony bundle.
• You accept single-maintainer, zero-dependent risk with an internal test suite as the mitigation.

Look elsewhere when:

• You are on Laravel. The framework mismatch is disqualifying. Native alternatives: FormRequest (validation + authorization in one object), spatie/laravel-data (DTOs with casting, validation, and OpenAPI generation), or a small custom resolver bound in a service provider.
• You need maintenance or security-response commitments. 1 star, 0 dependents, and no downstream users means no ecosystem pressure to fix anything; there is no signal that anyone else has run this in production.
• You need OpenAPI/schema generation — that is a separate concern (Nelmio, Scramble, Scribe) and should drive the tool choice, not DTO hydration alone.
• You need nested/collection validation at scale; verify depth limits and error-message shape before committing, as these are the usual failure points of hand-rolled resolvers.
• Verify the release metadata. The listed last release of 2026-04-24 is a future date relative to normal build timelines; confirm tags and changelog against the repository directly before any dependency decision. A package with no composer.lock is correct for a library, but combined with the above it reinforces "read-only reference."

Recommended posture: run a one-week timeboxed spike, copy the pattern into Laravel conventions, and measure controller LOC and validation-defect count on two endpoints. Decide build-vs-fork on that data, not on the package's merits.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source Symplony-library that turns incoming HTTP request data into typed, validated objects before it reaches business logic. It is a 1-star, zero-dependent, single-maintainer project on a different framework than ours, so we are not recommending it as a dependency. We are recommending we adopt the pattern in-house — a contained, low-cost engineering standard that reduces boilerplate and malformed-input bugs on new API endpoints. Cost is one engineer-week; the risk is essentially zero because nothing third-party ships to production. This is a code-quality decision, not a platform bet.

For engineering: The pattern is worth standardizing on; this package is worth reading, not installing. On Laravel, we already have FormRequest and spatie/laravel-data covering 80% of it — the gap is controller-argument hydration for non-validated DTOs, which is a small resolver bound in a service provider. Spike it, benchmark LOC and defect rates on two endpoints, then write an ADR. If we ever move to Symfony, this repo is a useful prior-art reference and nothing more.

Risks to state plainly: single maintainer, no dependents (no one has validated it in production), framework mismatch for our stack, and release metadata that needs verification. Mitigation: fork or reimplement, keep it under our tests, and avoid any upstream merge path.