Symfony Json Request Laravel Package

Product Decisions This Supports

• Framework-parity decisions in a mixed PHP estate. If we run Symfony services alongside Laravel ones, this package narrows a small but real behavioral gap: Laravel hydrates $request->input() from a JSON body automatically, while vanilla Symfony does not populate the $request->request parameter bag from php://input. This package makes Symfony behave more like Laravel for downstream code that assumes parameter-bag access.
• Build vs. buy for request normalization. The package is a thin, MIT-licensed utility with a single responsibility. The real decision it informs is whether to vendor a ~50-line listener or write it in-house; both are cheap, so this is a low-stakes, reversible call rather than an architectural commitment.
• Symfony upgrade roadmap (7.x). v0.3.0 adds Symfony 7 support, which removes a blocker if we are planning a Symfony 6→7 upgrade and were considering this shim as part of that work. It also tells us the maintainer merges outside PRs, so the project is not fully abandoned — but a single compatibility PR is a maintenance signal, not a support commitment.
• Migration and consolidation roadmap. Useful as a temporary shim when consolidating Symfony endpoints into a Laravel application, or when extracting shared middleware/controllers that must run on both frameworks without branching on Request type.
• Webhook and third-party ingestion use cases. Endpoints that receive JSON payloads and hand off to legacy code expecting $request->request->get('field') benefit from a compatibility layer instead of rewriting consumers.
• Standardizing API contracts. Reinforces the decision to define whether our internal convention is "JSON body is first-class input" (Laravel-style) or "explicit deserialization into DTOs" (Symfony-style with the Serializer). This package only supports the first convention.
• Not a validator, not a deserializer. It does not replace FormRequests, symfony/serializer, or a DTO/hydration layer. Any roadmap item expecting schema validation, type coercion, or nested-object mapping still needs a separate solution.

When to Consider This Package

Consider it when:

• You maintain a Symfony service — now including Symfony 7 — whose controllers or third-party middleware assume POST parameters are populated, and clients send application/json.
• You are bridging Symfony and Laravel code paths and want consistent input access without framework conditionals.
• You need a throwaway compatibility shim during a migration, where a small vendored dependency is cheaper than editing dozens of call sites.
• You have read the source and are comfortable owning it — with a handful of stars, 0 dependents, and a single maintainer, treat it as sample code you adopt, not a dependency you rely on. The v0.3.0 Symfony 7 pull request improves the odds it will keep working across upgrades, but does not change the ownership calculus.

Look elsewhere when:

• The target is a Laravel application. Laravel already parses JSON bodies natively via $request->json() and $request->input(); adding this package creates redundancy and a second, divergent input path.
• The endpoint is on a critical or high-traffic path. There are still no meaningful adoption signals, no dependent packages, and no evidence of a test suite or security review. Request-body handling is attack-surface code; prefer in-house implementation with tests.
• You need validation, sanitization, or typed hydration. Use Laravel FormRequests plus API Resources, or Symfony's Serializer/Validator with DTOs. Silently merging untrusted JSON into the parameter bag can mask mass-assignment and type-confusion issues if consumers trust it implicitly.
• You need long-term vendor support, SLAs, or a security response process. One merged PR for framework compatibility is not a support process.
• Non-JSON content types, streaming bodies, or large payloads are involved — a naive json_decode of the whole body has memory implications worth assessing before adoption.

Overall recommendation: do not adopt as a dependency. The v0.3.0 Symfony 7 bump is welcome housekeeping and clears the version-compatibility objection, but it does not change the fundamentals — no tests, no dependents, one maintainer. Treat it as a reference implementation; a small internal listener with tests gives the same behavior with ownership and reviewability, and can be written against Symfony 7 directly. Reassess only if the project gains maintainers, tests, and downstream usage.

How to Pitch It (Stakeholders)

To executives: This is a tiny, single-purpose open-source utility that makes Symfony read JSON request bodies the way Laravel already does. Its newest release simply adds Symfony 7 support — routine upkeep, not new capability. It surfaces a real consistency question in our PHP estate — do our services handle JSON input the same way? — but it is not a strategic dependency: minimal adoption, no downstream users, one maintainer. My recommendation is unchanged: capture the pattern internally rather than take on the dependency, at a cost of roughly a day of engineering. The Symfony 7 support means it is no longer blocked on our upgrade path, so we can revisit cheaply if priorities change.

To engineering: The package bridges a genuine framework difference — Symfony's Request does not populate the parameter bag from a JSON body, Laravel's does. v0.3.0 adds Symfony 7 compatibility via a community PR, which is the only substantive change; there is still no visible test coverage. If we have Symfony endpoints consumed by code that expects $request->request->get(...), that's worth fixing deliberately: implement it in-house with tests and input validation, targeting the Symfony versions we actually run, and pair it with an explicit decision on DTO-based deserialization versus parameter-bag access. In Laravel services, use $request->json() and do not add this package.