Weave Code
Request Dto Resolver Laravel Package
macpaw/request-dto-resolver
macpaw/request-dto-resolver automatically maps incoming Laravel request data into typed DTOs, cutting boilerplate and keeping controllers clean. It resolves DTO constructor parameters, supports nested objects, and makes request handling more explicit, predictable, and easy to test.
Request DTO resolver bundle
Frequently asked questions about Request Dto Resolver
- Does macpaw/request-dto-resolver work with Laravel?
- No, not natively. Despite Laravel-oriented framing, it is a Symfony bundle that plugs into Symfony's argument resolver pipeline. Laravel uses its own container-based method injection and route-model binding for controller actions, so this package will not resolve DTOs there without a custom bridge or port. Treat Laravel use as an integration project, not a Composer install.
- How do I install macpaw/request-dto-resolver?
- In a Symfony application, run composer require macpaw/request-dto-resolver, register the bundle, and type-hint a DTO in a controller action signature. There is no service, database, or middleware to operate. For Laravel, installation is not supported without reimplementing the resolution step in a service provider or dispatcher.
- What does the request DTO resolver actually do?
- It maps HTTP request data such as route parameters, query strings, and body fields into typed DTO objects declared as controller arguments. That removes hand-written request hydration and pushes type coercion into the framework's argument-resolution phase. The result is cleaner controller signatures, but the mapping is implicit and needs careful contract design.
- Which Laravel versions are supported?
- None are officially supported. The package does not declare Laravel compatibility because its integration point is Symfony's ArgumentResolver and ValueResolver pipeline, which Laravel does not use for controller actions. Do not assume Laravel 10 or Laravel 11 support based on package descriptions that call it a Laravel package.
- How should I test DTO resolution?
- Because resolution happens during the framework's argument-resolution phase, test it with functional or HTTP tests that hit the controller and assert the resulting DTO state. Add explicit contract tests for route-attribute-bound DTOs, since version 1.1.1 had a regression in that core path that upstream CI did not catch. Unit-test DTO construction separately for validation and error semantics.
- Is implicit request-to-DTO mapping safe in production?
- It creates a mass-assignment surface. Auto-binding request payload fields to DTO properties can let clients populate fields the endpoint never intended to expose, so use an explicit allow-list and a design review gate rather than relying on code review alone. Also define deterministic 400 versus 422 error behavior and ensure stack traces are never leaked.
- What is the latest version and is it maintained?
- Version 1.1.2 is a patch release that restores route attribute lookup for DTO parameter resolution. It is non-breaking and shows two named contributors are active, which modestly improves the continuity picture. However, the 1.1.1 regression in a core resolution path shows upstream test coverage is not a sufficient safety net, so pin a version floor of 1.1.2 and add your own contract tests.
- What are alternatives to macpaw/request-dto-resolver?
- In Symfony, use the built-in MapRequestPayload and MapQueryString attributes or write a custom argument resolver. In Laravel, use Form Requests, spatie/laravel-data, or a custom container binding to hydrate DTOs. Those options are more idiomatic per framework and avoid the ecosystem mismatch this package carries for Laravel teams.
- Does it support nested objects and validation?
- It resolves DTO constructor parameters and supports nested objects according to the package blurb. Validation is composable but not fully owned by the package, and error semantics for type coercion failures, missing required fields, and validation errors are underspecified. You must define those contracts yourself and test them explicitly.
- Is it worth adopting for a Laravel project?
- Generally no. Ecosystem mismatch is the highest risk because a Symfony bundle cannot be dropped into Laravel, so the real work is a port rather than an integration. Adoption makes sense mainly in a Symfony application, or in a hybrid or migration estate where reusing DTO semantics is the goal. With minimal adoption and no formal support commitment, treat it as stable-in-intent but unproven in production.
Weaver
How can I help you explore Laravel packages today?