Request Object Resolver Bundle Laravel Package

Product Decisions This Supports

• Input-boundary standardization (feature-level): The bundle deserializes HTTP request parameters into typed DTOs, so it supports decisions about how we model API input — typed objects vs. associative arrays vs. form objects. Every new endpoint inherits whichever pattern we pick, so the decision compounds.
• Build vs. buy for request mapping: The surface area is small (an argument resolver plus serializer wiring). A working equivalent is roughly 1–2 engineer-days against Symfony's Serializer + a custom ArgumentResolver. That keeps this a genuine build-vs-buy call rather than a foregone "buy." The v2.0.0 "add your own resolvers to the resolve chain" feature trims that estimate slightly — you can extend the package's resolver chain instead of forking it — but it does not change the underlying risk profile: 9 stars, 0 dependents, and a single release line that started in Dec 2023.
• Roadmap scoping for contract-first APIs: If the roadmap includes OpenAPI-driven or schema-first endpoints, a DTO resolver is a prerequisite for the generated-client / validation story. This package is one candidate in that evaluation, not a decision in itself.
• Use cases it plausibly serves: webhook ingestion with varying payload shapes, query-string filters mapped to filter objects, multi-format request bodies (JSON/form), controller slimming in a Symfony service, and — new in v2.0.0 — endpoints needing bespoke resolution rules (custom resolvers in the chain) or attribute-driven mapping edge cases the earlier release did not handle cleanly.
• Framework-fit decision — this is the important one: Despite being scoped as a "Laravel/PHP package," this is a Symfony bundle, not a Laravel package. It cannot be adopted in a Laravel codebase without essentially rewriting it. If the question is "Laravel request DTOs," the real candidates are Laravel FormRequests (already in-framework), spatie/laravel-data, or custom route-binding resolvers. This package should be removed from the Laravel comparison set entirely.
• Upgrade-risk signal: v2.0.0 is a major version bump whose notes list only additive features ("working around attributes," custom resolver chain) with no migration or breaking-change guidance. For a dependency sitting at the API boundary, an unexplained major bump is itself a data point about the project's release discipline.

When to Consider This Package

Consider it only when all of the following hold:

• The service is on Symfony (not Laravel), and Symfony's Serializer is already the serialization standard in the codebase.
• The team is on a Symfony version older than 6.3, or has a specific gap that #[MapRequestPayload] / #[MapQueryString] does not cover — because the package's own pitch ("a better alternative for new Symfony request DTO resolvers") is a claim against native functionality that has since shipped and is maintained by the core team.
• You have a concrete need for custom resolution logic — the v2.0.0 resolver chain is the one capability here that is genuinely awkward to replicate on top of native attributes without writing your own resolver.
• You have appetite to own and patch a small vendor dependency: 9 stars and 0 dependents means near-zero community backstop and no realistic expectation of upstream fixes on your timeline. Treat it as vendored code with a maintainer attached, not as a supported library.
• The DTOs are simple and the mapping is attribute- or resolver-driven; you're not relying on it for complex validation, nested polymorphism, or error-message quality without verifying those paths yourself.

Look elsewhere when:

• The target is Laravel. Full stop — framework mismatch.
• Native coverage is sufficient. Symfony's #[MapRequestPayload]/#[MapQueryString] are core-maintained, documented, and upgrade-safe; the default should be to prefer them and require this package to justify itself against them. The v2.0.0 resolver chain is an argument for the package only on endpoints that actually need custom resolution — not as a general reason to switch.
• You need an SLA, security-patch cadence, or a dependency that passes procurement/provenance review. A single-maintainer project that jumped to v2.0.0 without published migration notes will not clear most of those gates.
• Validation and deserialization must be co-located with rich, localized error reporting — evaluate symfony/validator integration or a data-mapping library with active maintenance instead.

How to Pitch It (Stakeholders)

To executives: This is not a business-level decision and I would not bring it to you as one. It is a small, single-maintainer Symfony utility for turning HTTP requests into typed objects. The v2.0.0 release adds extensibility (custom resolvers in a chain) and some attribute-handling fixes; it does not change the strategic picture. The point worth your attention remains narrow: it surfaced in a "Laravel/PHP package" evaluation, and it is not a Laravel package at all. That is a sourcing-hygiene issue in how we scan and qualify dependencies — worth a process fix, not a budget line.

To engineering: It does one job — deserialize request parameters into DTOs via an argument resolver — and does it in a framework we may not even be using. v2.0.0 adds a pluggable resolver chain and attribute workarounds, which is a real improvement in flexibility and removes part of the "fork it to extend it" argument. It does not move the risk markers: 9 stars, 0 dependents, effectively one maintainer, and now a major version bump published without migration notes. Recommendation: do not adopt by default. If we're on Symfony, prototype against core #[MapRequestPayload] / #[MapQueryString] first — the package still positions itself as an alternative to exactly that, and native wins on maintenance and upgrade safety. If native mapping genuinely falls short for a specific endpoint, prefer either the in-house resolver (1–2 days) or pin this package explicitly as vendored code with a named owner and a regression test suite, since v2.0.0's resolver chain now makes an extended fork harder to reason about across upgrades. This is the layer where a silent behavioral change hurts most. If we're on Laravel, close the ticket; the correct comparison set is FormRequests and spatie/laravel-data.