Request Resolver Bundle Laravel Package

Getting Started

1. Install and register. composer require gchernikov/request-resolver-bundle. There is almost certainly no Flex recipe, so add it manually to config/bundles.php:

   GChernikov\RequestResolverBundle\RequestResolverBundle::class => ['all' => true],
   

2. Read the source before the README. With one star and zero dependents, the src/ directory and tests/ are the real documentation. Look first for:
   • The argument resolver class (usually tagged controller.argument_value_resolver).
   • The attribute(s) used to mark controller parameters.
   • Any factory/denormalizer that turns Request data into a DTO.
   • The composer.json Symfony/PHP version constraints — this determines whether it will even boot on your stack.
3. First use case. Start with one read-only endpoint: a DTO with public typed properties (or a constructor), a controller action that type-hints the DTO, and the bundle attribute on the parameter. Verify with bin/console debug:container --tag=controller.argument_value_resolver that the resolver is registered with a sensible priority.
4. Laravel mental model. The closest Laravel analogue is a FormRequest combined with route-model binding: the DTO is your validated input object, and the resolver is the container doing the injection. Expect less batteries-included behavior (no automatic 422 JSON response, no authorize() hook) unless the bundle ships it.

Implementation Patterns

• Type-hint DTOs in controllers. The core workflow is:

  public function __invoke(#[FromRequest] CreateOrderDto $dto): Response
  

  Let the bundle populate the DTO from query/body/route data instead of manually calling $request->query->all().
• Attribute-driven source selection. Use the bundle's attribute to control whether data comes from the body, query string, or route parameters. Keep one DTO per source unless the bundle explicitly merges them; merging is where surprising collisions happen.
• Validation in the DTO. Put Symfony Validator constraints on DTO properties and inject ValidatorInterface (or rely on the bundle's validation hook if present). Return a consistent error payload from a kernel exception listener rather than per-controller boilerplate.
• Immutable DTOs. Prefer readonly classes or constructor promotion with no setters. This prevents controllers from mutating input and makes the DTO safe to pass into services.
• Nested DTOs. For arrays of objects, confirm the bundle uses the Serializer with ObjectNormalizer/PropertyInfo; otherwise nested construction will silently produce arrays or fail. Test one nested payload early.
• Reuse across controllers. Keep DTOs in an App\Dto namespace and share them between HTTP controllers and console/message handlers so the same validation rules apply. Convert the DTO to a command/message at the controller boundary.
• Testing. Use KernelBrowser or Request::create() and assert both the resolved DTO (via a test controller) and the validation failure path. Add a unit test around the resolver if you customize it.
• Customization. If the default behavior is close but not exact, subclass the resolver or register a higher-priority ArgumentValueResolverInterface rather than forking the bundle.

Gotchas and Tips

• Audit before production. One star and zero dependents means no community pressure-testing. Read every line of the resolver, pin the exact version in composer.json, and be prepared to fork. Check the last commit date and open issues.
• Symfony has native alternatives. On Symfony 6.3+, #[MapRequestPayload] and #[MapQueryString] cover most of this ground using the Serializer and Validator. Adopt this bundle only if it demonstrably adds something (e.g., older Symfony support, custom source merging) — otherwise you are taking on maintenance risk for native functionality.
• Mass assignment. Do not bind request data directly to Doctrine entities. DTOs should explicitly declare every accepted field; verify the bundle does not use a permissive normalizer that populates undeclared properties.
• Content-Type edge cases. Test application/json, application/x-www-form-urlencoded, empty bodies, and malformed JSON. Many small resolvers assume one content type and throw unhelpful errors on the others.
• Route vs. body collisions. If route parameters and body fields share names, confirm precedence. This is a common source of "why is my ID null" bugs.
• Validation error formatting. The bundle likely throws a validation exception with no HTTP mapping. Add an exception listener that converts it to a 422 with field-level errors, or you will leak stack traces.
• Debugging. If the DTO is not being injected, check resolver priority (debug:container --tag=controller.argument_value_resolver), confirm the parameter has the required attribute/type, and use the profiler's request/response panel. A dd()-style dump inside the resolver is often faster than guessing.
• Extension points. Look for compiler passes, a configurable DTO factory, or a service you can decorate. Those are the safe seams for customization; avoid editing vendor code.
• Ecosystem mismatch. As a Laravel developer, note that this is a Symfony bundle: no service providers, no Eloquent, no FormRequest lifecycle. Budget time for Symfony's argument resolver and Serializer conventions before judging the bundle's ergonomics.