Request Converter Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on request-to-object mapping. The package addresses a real, recurring need: turning raw HTTP request payloads into typed PHP objects (DTOs) so controllers, validators, and domain services stop hand-parsing $request->request->all(). That is a candidate for "buy" (adopt a package) versus "build" (30–80 lines of in-house mapping + Symfony's Serializer/Validator).
• API input normalization roadmap item. If the roadmap includes webhook ingestion, multi-tenant payloads, or accepting JSON + form-encoded bodies on the same endpoint, a converter layer is the kind of infrastructure that determines whether those features are one sprint or three. This package is a reference point for scoping that work, not necessarily the implementation.
• Feature-level scope control. A converter lets you keep controllers thin and push validation/typing into a single seam. That influences estimates on any feature where "accept and validate input" is a line item — checkout, signup, integrations, admin bulk actions.
• Platform/framework decision, not a library decision. ⚠️ Critical correction to the brief: this is a Symfony bundle, not a Laravel package. For a Laravel codebase, this is a non-option — Laravel's FormRequests, Validator, and ->validated() already cover the use case. The realistic decision it informs is "what does our Symfony service use for payload mapping," which is an architecture question, not a procurement one.
• Dependency inventory / supply-chain posture. With 1 star, 0 dependents, and a 0.005 relevance score, adopting this is a policy decision about accepting unmaintained third-party code into the request path — the highest-trust zone in the application. That decision should be made deliberately and recorded, not made by a developer adding a line to composer.json.

When to Consider This Package

Reasonable to evaluate only if all of the following hold:

• The target service is Symfony, not Laravel.
• The team is on a Symfony version older than 6.3, i.e., before #[MapRequestPayload] and #[MapQueryString] shipped natively. On 6.3+, Symfony already solves this in core — there is no gap for this bundle to fill.
• The team has an explicit constraint against API Platform or a full serializer-based mapping layer, and wants something small and localized.
• Someone on the team is willing to read the source (it's MIT, small enough to audit) and own a fork or vendored copy.

Look elsewhere — or don't adopt — when:

• Laravel is the stack. Hard stop. Not applicable.
• You need confidence in maintenance. 1 star and 0 dependents means no community backstop, no issue triage, no security advisories. Anything touching request deserialization is an attack surface; unmaintained mapping code is a liability you inherit permanently.
• You need documentation or onboarding speed. A near-zero-signal package typically means the README is the only spec. Budget for reverse-engineering behavior from source, and for the bus-factor of exactly one person understanding it.
• You're on modern Symfony. Use #[MapRequestPayload] (core), or symfony/serializer + symfony/validator directly, or API Platform if you want the whole resource layer. All three have maintainers, docs, and CVE processes.
• The need is genuinely 50 lines of code. A small RequestConverter service that maps an array to a constructor via reflection or a match statement is cheaper to own than a dependency — and you keep the tests.

Recommendation: Do not adopt as a dependency. Treat it as a pattern reference — read the source, extract the idea (a single seam between HTTP and typed input), and implement it in-house or lean on native Symfony. Revisit only if the repository shows sustained commits, tests, and dependent projects, which it currently does not.

How to Pitch It (Stakeholders)

To executives: This is a very small, single-maintainer Symfony component that converts incoming HTTP requests into typed PHP objects. The underlying idea is sound and worth copying; the package itself is not worth depending on. One star and zero downstream users means no one else is betting their uptime on it, and it sits in the request path — the part of the system that touches untrusted input. Recommendation: no adoption. We can get the same benefit from Symfony's built-in request mapping (6.3+) or roughly a day of in-house work, with no supply-chain exposure and no orphaned dependency to migrate off later in an audit or incident.

To engineering: The problem it names is real — controllers doing ad-hoc array digging, validation scattered, no single place to enforce input contracts. But this bundle offers no maintainer coverage, no docs beyond the README, no tests we can point to, and it's Symfony-only, so it's irrelevant to our Laravel services. On Symfony 6.3+ use #[MapRequestPayload]; otherwise a small converter service plus symfony/serializer and symfony/validator gives us the same seam with code we own. If someone wants to spike it, timebox it, read the source first, and come back with a diff against the native approach — not a composer require.