- Is pfilsx/dto-param-converter-bundle compatible with Laravel?
- No. It is a Symfony bundle that registers a param converter into Symfony's controller argument resolution, and Laravel has no equivalent extension point, so installing it in a Laravel app will not give you DTO mapping. For Laravel, use a FormRequest that returns a typed DTO or a mature package such as spatie/laravel-data. Treat this repository as a design reference rather than a dependency.
- How do I install and register this DTO param converter bundle in Symfony?
- Require the package with Composer, enable the bundle in config/bundles.php, then type-hint your DTO as a controller argument and configure the converter as shown in the README. The install itself is small, but the last release was 2023-03-27, so verify it resolves against your Symfony and PHP versions first. Run the registration on a throwaway branch before touching your main application.
- Which Symfony and PHP versions does this bundle support, and is Symfony 7 supported?
- The last release is from March 2023, so its constraints target Symfony 5/6-era and the PHP versions current at that time; Symfony 7 support is not evidenced. Run Composer resolution against your actual version matrix to see whether it installs at all. If resolution fails, plan for a fork or pick a maintained alternative.
- Does it integrate with Symfony Validator and return 422 for validation failures?
- That is not documented as a standardized contract. The bundle surfaces conversion errors as exceptions, and whether violations consistently map to 400 or 422 is unclear. Add an integration test with an invalid payload and a deliberate type mismatch to capture the real response before relying on it.
- Does it support nested DTOs, collections, and query-string or route parameter binding?
- These are open questions rather than confirmed features, and the safest assumption is that only flat JSON body binding is well covered. Test each binding type you need, including body, query string, route parameter, and a nested DTO. If any of those fail, you are looking at a fork rather than configuration.
- Is hydration constructor-based or reflection-based, and is over-posting a risk?
- The available assessment does not confirm which mechanism is used, and it flags over-posting as a real exposure. Auto-hydrating a DTO from a raw payload is a mass-assignment surface unless binding is constructor-based and explicit. Inspect the converter code and keep DTOs limited to fields clients are allowed to supply.
- What happens on malformed or non-JSON payloads?
- Failure semantics are not a standardized contract, so an unhandled exception or a 500 is plausible. Send malformed JSON, an empty body, and a wrong content type, then record what actually comes back. If you need consistent client-safe 400 responses, wrap the converter in your own adapter.
- Is this package actively maintained and safe for production use?
- The signals point to high risk: seven stars, zero dependents, a last release of 2023-03-27, and a bus factor of one. There is no observable production usage and no security patch cadence. It is acceptable for a prototype behind an adapter, but risky as a core dependency.
- What is the best Laravel alternative for mapping request data into DTOs?
- Use a FormRequest with validation rules that builds a typed DTO, or adopt spatie/laravel-data if you prefer a mature maintained dependency. Both give explicit, testable mapping without pulling in a Symfony-only bundle. Keep controllers depending on your own resolver interface rather than a concrete package.
- How should I integrate this bundle safely in a Symfony application?
- Introduce an application-level seam such as a RequestDataResolver interface and implement it once with this bundle inside a single adapter file. Controllers should never reference the bundle's attributes or classes directly. If the package stalls or blocks an upgrade, you replace one adapter instead of auditing every controller.