Symfony Json Request Transformer Laravel Package

Product Decisions This Supports

• Framework upgrade sequencing (Symfony). This listener exists to solve a gap that Symfony closed natively in 6.3 (Request::toArray(), #[MapRequestPayload], improved json request format handling). Its archived status is a concrete data point for prioritising a Symfony 5.x → 6.3+/7.x upgrade: the upgrade removes a dependency rather than adding one.
• Build vs. buy vs. delete. The entire behaviour is ~50–100 lines of code listening on kernel.request: check Content-Type: application/json, json_decode the body, replace the request parameter bag, return 400 on parse failure. For a PM, this is a "delete/buy-nothing" case, not a procurement case — the decision is whether to own a small internal listener or carry an unmaintained vendor package.
• Framework selection for new services. If your team is choosing between Symfony and Laravel for a JSON-API product, note that Laravel's Illuminate\Http\Request already merges JSON bodies into the input source via $request->json() / $request->all(). This package is therefore redundant in Laravel — flagging it in a Laravel backlog is a sign of copy-pasted research, and the PM should redirect the team to native request handling and FormRequests.
• API contract standardisation. Decisions about how malformed JSON, wrong Content-Type, and empty bodies are handled (400 vs. 415 vs. silent empty array) are product-visible API behaviours, not just plumbing. This package makes an implicit choice; your API style guide should make it explicitly.
• Supply-chain / dependency policy. 124 stars, 0 dependents, archived since 2023, single-maintainer heritage from an agency lab. This is a useful worked example when drafting a rule like "no archived packages in production services" or an SBOM/allowlist gate in CI.
• Roadmap hygiene / technical debt burn-down. Tickets like "JSON body not populated for POST /orders" are a recurring class of bug in pre-6.3 Symfony apps. Framing the fix as a platform upgrade (one decision) rather than per-endpoint patches is a roadmap-level trade-off worth surfacing.

When to Consider This Package

Consider it only when all of the following hold:

• You are on Symfony ≤ 6.2 (or a legacy Silex/older stack) and an upgrade is genuinely blocked for a quarter or more.
• You need JSON request bodies to appear in $request->request so that existing controllers, form types, or ParamConverters keep working without per-action changes.
• You accept ownership: fork it, vendor it into src/, add tests, and pin the commit. Do not depend on the upstream repo.
• The service is internal or low-risk, and you have a tracking ticket to delete it at the next framework upgrade.

Look elsewhere when:

• You are on Laravel. Native $request->json(), $request->input(), and FormRequests already cover this. No package needed.
• You are on Symfony 6.3+. Use #[MapRequestPayload] with the Serializer and Validator — you get typed DTOs and validation errors for free, which is the actual product value.
• You need validation, not just decoding. Decoding into a parameter bag gives you untyped arrays; contract enforcement belongs in DTOs + constraints, not a request listener.
• You have strict dependency governance. Archived, no security response path, no maintainer. That is a risk-register entry, not a convenience.
• You need content negotiation, versioning, or OpenAPI fidelity. These require a deliberate request-parsing layer you control.

How to Pitch It (Stakeholders)

For executives (one paragraph): A team member has proposed adding a small third-party library to handle JSON request bodies. My recommendation is not to adopt it. It is an archived, single-purpose Symfony listener (last release January 2023, no downstream dependents) that does roughly a hundred lines of work our own engineers can own outright — and in our Laravel services it duplicates behaviour we already get for free. The strategic move it points to is a framework upgrade: modern Symfony handles typed JSON payloads natively, which removes this dependency and an entire class of "body came through empty" bugs. Cost of the alternative is low; cost of carrying an unmaintained package in a payment- or customer-facing path is not.

For engineering (the ask):

• Do not add qandidate/symfony-json-request-transformer as a Composer dependency.
• If a legacy Symfony service needs the behaviour now, inline a listener on kernel.request with priority above the router (>32), covering: Content-Type check, json_decode with error handling mapped to HTTP 400, and a documented merge policy into the request bag. Ship it with unit tests and a code comment linking the removal ticket.
• For Laravel services, close the ticket: $request->json() / FormRequests already do this. Add a line to the API style guide so nobody re-raises it.
• For Symfony services able to upgrade, put #[MapRequestPayload] + Serializer/Validator on the roadmap; treat the custom listener as temporary scaffolding.
• Add "archived dependency" to the dependency-review checklist so this decision is made once, not per ticket.

Success criteria for the PM: the JSON-body bug class stops appearing in triage, no new third-party dependency enters the SBOM, and the removal of any temporary listener is tracked to a dated milestone rather than left open-ended.