Json Request Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for JSON body parsing. The decision this package actually informs is narrow: do we adopt a third-party listener to hydrate Symfony's $request->request parameter bag from application/json bodies, or do we write and own that logic ourselves? Given the package's profile (6 stars, 0 dependents, score 0.27, opportunity 16.79), the realistic answer is "borrow the pattern, own the code" — vendor or reimplement rather than take a runtime dependency.
• A framework-fit check before anything else. This is a Symfony bundle, not a Laravel package. Bundles are registered via bundles.php and depend on the Symfony HTTP kernel event system; Laravel has no equivalent registration path. If the motivating need is "Laravel-like JSON handling in our Symfony app," this is on-target. If the team is actually on Laravel, the decision is a non-starter — Laravel's Request already resolves JSON input via input()/json(), so there is nothing to buy.
• Standardizing request handling across a controller layer. The real product value is consistency: controllers stop hand-rolling json_decode($request->getContent(), true) and instead read from a single, predictable place. That is a maintainability and onboarding decision, not a feature decision — it pays off in proportion to how many endpoints currently duplicate that boilerplate.
• Roadmap sequencing for an API layer. Adopting this is a stopgap, not a destination. It postpones the more valuable investment — typed request DTOs with validation — by roughly one sprint. The roadmap question is whether the team wants the cheap uniform fix now and DTOs later, or should skip straight to #[MapRequestPayload] / a serializer-based approach and avoid a throwaway step.
• Migration and interop decisions. Useful when porting endpoints from a Laravel codebase or merging teams with mixed framework backgrounds, where engineers expect $request->request->get('foo') to "just work" for JSON. It reduces cognitive translation cost during a migration window.
• Supply-chain and dependency posture. Zero dependents and a low opportunity score are a signal to treat this as source code to review, not a dependency to trust. The decision it supports is "fork with a pinned commit and an internal owner," which is a governance call a PM should make explicitly rather than let happen by default.

When to Consider This Package

Consider it when all of the following hold:

• The codebase is Symfony (not Laravel, not plain PHP), and the Symfony major version is confirmed compatible by reading composer.json — do not assume.
• You have a meaningful number of existing controllers reading $request->request->get(...), so a global body-parsing listener delivers immediate, broad cleanup rather than solving one endpoint.
• The need is genuinely just parsing — flat JSON into the parameter bag — with no requirement for nested DTO hydration, validation, content negotiation, or structured error responses.
• The team is willing to vendor the code into the repo or fork it under your org, assign an owner, and add tests. At 6 stars and no dependents, you are the maintainer in practice.
• You have done a security pass on the implementation: json_decode depth limits, request body size limits, behavior on malformed JSON (does it 400 cleanly or leak a PHP warning?), and whether it mutates the request in ways other middleware doesn't expect.

Look elsewhere when:

• You are on Laravel. Native behavior already covers this; a Symfony bundle is the wrong artifact entirely.
• You are on Symfony 6.3+. #[MapRequestPayload] (and #[MapQueryString]) with the Serializer gives typed, validated request objects with no third-party dependency. That is a stronger default and a better long-term story.
• You need validation, nested objects, or error contracts. Pairing a parse-only listener with a separate validator recreates the boilerplate you were trying to remove.
• You are building an API product, not an internal API. API Platform or FOSRestBundle plus Serializer covers parsing, validation, serialization, and error formats as one coherent stack — worth the heavier footprint.
• You need streaming, large payloads, or high-throughput endpoints, where eagerly decoding the whole body on every request is the wrong trade.
• Nobody will own it. Any dependency with this little community signal that the team won't fork or test is a future incident with no upstream to escalate to.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed utility that removes duplicated JSON-parsing code from Symfony controllers. It is not a strategic investment and carries no license cost. The material risk is maintenance: with 6 stars and zero dependent projects, there is effectively no upstream support, so I would only approve it as code we copy in and own — a few days of engineering, not a vendor relationship. If we are on Laravel, it does not apply at all.

For engineering: One listener that decodes application/json bodies into the request parameter bag so controllers read $request->request->get() uniformly. Before adopting: verify Symfony version compatibility in composer.json, read the full source (it is small), confirm the malformed-JSON path returns a 400 rather than a warning, and check body-size and decode-depth handling. Recommendation is to vendor or reimplement rather than add it as a Composer dependency — the logic is small enough to own outright, and that removes the abandonment risk entirely. Treat it as a bridge: the durable target is #[MapRequestPayload] with typed DTOs on Symfony 6.3+, and we should schedule that rather than let the bridge become the architecture.