Request Converter Bundle Laravel Package

Getting Started

Install and register

composer require gepur-it/request-converter-bundle

Since this is a Symfony bundle, confirm registration in config/bundles.php:

return [
    // ...
    GepurIt\RequestConverterBundle\RequestConverterBundle::class => ['all' => true],
];

If config/bundles.php does not include it after composer require, add it manually — some small bundles ship without a Flex recipe, so auto-registration is not guaranteed.

Where to look first

1. vendor/gepur-it/request-converter-bundle/src/ — the service class and any controller trait/attribute are the real documentation.
2. DependencyInjection/ — tells you the service ID (usually gepur_it.request_converter or similar) and what is autowirable.
3. Resources/config/services.* — reveals constructor dependencies (Serializer, Validator, ParameterBag) so you know what it can actually do.
4. The README — but for a 1-star package, treat the source as ground truth; README snippets may be stale.

First use case

The bundle's purpose is turning a raw Symfony\Component\HttpFoundation\Request into a typed object instead of hand-reading $request->request->get(...) or json_decode($request->getContent()). Start by replacing one manual JSON decode in an existing controller:

// Before
$data = json_decode($request->getContent(), true);
$dto  = MyDto::fromArray($data);

// After (adjust to the actual API surface you find in src/)
$dto = $this->requestConverter->convert($request, MyDto::class);

That single swap is the fastest way to validate whether the bundle fits your codebase.

Implementation Patterns

Controller-level DTO hydration

The primary pattern is: define a plain PHP DTO with public typed properties, then convert the request into it before your application logic runs.

final class CreateOrderInput
{
    public string $reference;
    public array $lines = [];
    public ?string $note = null;
}

#[Route('/orders', methods: ['POST'])]
public function create(Request $request): Response
{
    $input = $this->requestConverter->convert($request, CreateOrderInput::class);
    // $input is now a typed object
}

Keep DTOs free of framework code — that makes them reusable across controllers, console commands, and tests.

Layer the conversion

For day-to-day use, treat the converter as the transport→DTO boundary and nothing more. Put business validation in Symfony's Validator afterward rather than expecting the converter to enforce rules:

$input = $this->requestConverter->convert($request, CreateOrderInput::class);

$errors = $this->validator->validate($input);
if (count($errors) > 0) {
    throw new ValidationFailedException($errors);
}

Argument-resolver style (if supported)

If the bundle exposes an argument resolver or attribute, prefer it over injecting the service into every controller — it keeps controllers lean and makes the intent explicit:

public function create(#[ConvertRequest] CreateOrderInput $input): Response
{
    // ...
}

Check src/ for an ArgumentResolver, Attribute, or Controller trait before writing manual wiring.

Integration tips

• Register DTOs under serializer config if the bundle leans on symfony/serializer, so property naming and denormalizers behave predictably.
• Wrap the call in a small domain-specific method (mapToInput()) inside a base controller if you need consistent error handling for malformed payloads.
• Add an integration test per controller that sends a real JSON body — this is the cheapest way to catch mapping regressions when the bundle's internals change.

Gotchas and Tips

Small-package risk

This bundle has 1 star and 0 known dependents. That is fine for internal use, but budget for the possibility that it is unmaintained. Before adopting:

• Pin the version in composer.json.
• Verify it supports your Symfony version (check composer.json require in the vendor folder).
• Prefer it only if it removes real boilerplate; Symfony's own #[MapRequestPayload] (7.x) or symfony/serializer may already cover the same ground.

Bundle registration

Missing bundle registration is the most common failure — you'll get a ServiceNotFoundException for the converter. If the service name is unclear, run:

php bin/console debug:container | grep -i converter

Serializer configuration quirks

If conversion relies on the Serializer, mismatched property names (snake_case payload vs camelCase DTO) silently result in null properties rather than errors. Enable serializer name_converter (MetadataAwareNameConverter) or add explicit #[SerializedName] attributes.

Silent empty results

Malformed or empty request bodies often produce an object with default values instead of throwing. Always validate the resulting DTO — never assume a successfully converted object means a valid payload.

Debugging conversion failures

• Catch and log the underlying exception (NotNormalizableValueException, MissingConstructorArgumentsException) to see which field failed.
• Dump $request->getContent() first — a 200 with a blank body looks identical to a conversion bug.
• For nested DTOs, test the mapping in isolation with a unit test rather than through the full HTTP stack.

Extension points

If the bundle permits custom normalizers/denormalizers or a custom converter implementation, register yours with a higher priority tag (e.g., serializer.normalizer with priority) instead of forking. Because the package is small, be prepared for the extension surface to be thin — the pragmatic fallback is a thin wrapper service of your own that delegates to symfony/serializer, keeping the bundle optional and replaceable.