Request Bundle Laravel Package

Product Decisions This Supports

• Controller/DTO convention standardization. The package addresses one narrow ergonomic question: should a typed request object be injected directly as a controller argument instead of pulling the framework Request and hydrating manually? That is a real convention decision for teams standardizing controller signatures — but the decision is worth far more than the package itself.
• Framework target resolved — and it changes the answer. Release 0.3.3 confirms this is a Symfony bundle, not Laravel. It now supports Symfony 7.2 and higher only. Two consequences: (a) the Laravel/FormRequest comparison is moot and should be dropped from any decision record, and (b) on every version it supports, Symfony already ships #[MapRequestPayload] / #[MapQueryString] natively (since 6.3/6.4). The package's remaining differentiator is thin.
• Build vs. buy — and the answer remains "build." The capability is a thin argument-value-resolver plus an attribute — realistically a few dozen lines of glue with tests. The decision to make is "do we want typed request arguments as a house convention, and do we want the framework-native attributes or our own?", not "should we take this dependency?" This package is best treated as a pattern reference or spike input, not a foundation.
• Roadmap impact: none, and now slightly negative for platform teams. With a handful of stars, no dependents, and three patch releases, this cannot anchor a roadmap item. The 7.2-only floor is a hard ceiling: it excludes Symfony 6.4 LTS (the version most enterprises are on through 2027) and 7.0/7.1, so adoption would force a framework upgrade to gain an ergonomic nicety. That is a cost-inverting dependency.
• Use cases where it would matter (if adopted at all): greenfield Symfony 7.2+ services with a deliberate preference for a vendored, minimal resolver over the native attributes; internal tools where an engineering owner wants to read a compact reference implementation. Low or zero value where you can simply use #[MapRequestPayload] with symfony/serializer + validator — which is the default supported path.
• A remaining risk item: version-policy signal. The 0.3.3 change note ("7.2 and higher only") is a breaking compatibility drop shipped in a patch release (0.3.2 → 0.3.3). That is the substantive finding here: the project's versioning does not signal breaking changes, so pinning by constraint will not protect you across future releases.

When to Consider This Package

Consider it when:

• You are on Symfony 7.2+ specifically, and have consciously decided against the native #[MapRequestPayload] / #[MapQueryString] attributes — with a written rationale, because "we didn't know they existed" is the more likely explanation.
• You want a minimal, MIT-licensed implementation to read, fork, or vendor — and you are comfortable owning that fork permanently.
• The scope is genuinely a small internal tool where a one-line controller signature is the winning ergonomic.
• You have an engineering owner willing to pin the exact version (not a range), review the resolver code, and accept responsibility for it after the author stops responding.

Look elsewhere when:

• You are on Laravel. Out of scope — this is a Symfony bundle. Use FormRequest.
• You are on Symfony 6.4 LTS, 7.0, or 7.1. 0.3.3 explicitly dropped you; 0.3.2 or earlier is the ceiling and is unsupported going forward. Upgrading the framework to adopt a binding helper is not a justified trade.
• You are on Symfony 7.2+. Use #[MapRequestPayload] with symfony/serializer + validator. It is maintained by the framework, covered by the framework's BC policy, and does the same job.
• You need anything beyond binding. Validation rules, authorization, transformation, serialization, and OpenAPI generation belong to mature stacks — not to a binding helper.
• Maintenance, security response, or support matters at all. No dependents means no downstream scrutiny and a bus factor of roughly one. There is no ecosystem signal that this code has been exercised in production by anyone but its author.
• You need predictable upgrade behavior. 0.3.3 is the evidence: a Symfony-version floor was raised in a patch release. Semver here does not mean what your dependency policy assumes.

How to Pitch It (Stakeholders)

To executives — recommendation: no-go, no budget required. This is a small Symfony developer-ergonomics add-on: it lets a controller receive a typed request object directly as an argument. The 0.3.3 release confirms two things. First, it only supports Symfony 7.2 and newer, so adopting it would mean being on — or moving to — a recent framework version to gain a convenience. Second, on that same version the framework already provides this capability natively, at no cost and with framework-level support. Adopting the package would add a dependency with effectively zero community adoption, no support path, and a single maintainer, whose latest patch raised the minimum framework version without a major-version bump. There is no product, revenue, or reliability upside. The right move is to record the pattern, decline the dependency, and if engineering wants the ergonomics, use the native attributes or implement the resolver internally behind our own code and tests.

To engineering — read it, don't require it; and default to the native attributes. It is a clean, minimal example of an argument-value-resolver binding a request object into a controller signature, worth 30 minutes of reading. But the conclusion has firmed up: the framework target is Symfony, the supported floor is 7.2, and #[MapRequestPayload] / #[MapQueryString] cover the same ground natively on every version this package now supports. If we want this convention, standardise on the native attributes and document the serializer/validator wiring; if we want a house-specific variant, implement it as an internal attribute plus resolver with our own tests. Also note for our dependency policy: this project shipped a framework-version floor bump in a patch release, so if it ever does enter the tree, pin the exact version rather than a range.