Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Request Bundle

Request Bundle Laravel Package

jrm/request-bundle

jrm/request-bundle is a Symfony bundle that streamlines HTTP request handling, giving you a structured way to validate incoming data, map parameters to typed objects, and keep controllers thin. Drop-in integration and sensible defaults make it easy to adopt in existing projects.

View on GitHub
Deep Wiki
Context7

Makes it easy to get your own request as a controller argument

Frequently asked questions about Request Bundle
Can I use jrm/request-bundle in a Laravel application?
No. jrm/request-bundle is a Symfony bundle registered through standard Symfony bundle configuration, so it has no Laravel service provider, no facade, and no framework-agnostic core you could wire in manually. If you are building on Laravel, use FormRequest validation, validated DTOs, or a package such as spatie/laravel-data instead. Treat this package as out of scope for a Laravel codebase.
Which Symfony versions does jrm/request-bundle support?
Release 0.3.3 sets the platform floor at Symfony 7.2 and higher only. Symfony 5.4, 6.0 through 6.2, 6.3 through 7.1, and the 6.4 LTS line cannot install the package at all because Composer will reject the constraint. Check the composer.json constraint of the exact tag you plan to use before adding it to a project.
Does jrm/request-bundle work with Symfony 6.4 LTS?
It does not. Symfony 6.4 is supported upstream into late 2027 and is where many production estates still sit, but this package requires 7.2 or newer. That means the versions where a request-mapping helper would add the most value are exactly the versions where it cannot be installed. If you are on 6.4 LTS, plan on the first-party attributes or an in-house resolver.
How do I install jrm/request-bundle?
Install it with Composer using composer require jrm/request-bundle, then enable the bundle in config/bundles.php as you would any Symfony bundle. The setup is intentionally minimal, with sensible defaults and little required configuration. Confirm your Symfony version is 7.2 or above first, otherwise the install will fail on the platform constraint.
How much configuration does jrm/request-bundle need?
Very little. The bundle is designed as a lightweight, drop-in addition with sensible defaults, so most projects only register it in config/bundles.php and start using the request helpers. Any optional bundle configuration lives under the standard config/packages directory. Because the package is at 0.x, review the CHANGELOG for each patch release in case defaults or supported platforms shift.
What does jrm/request-bundle actually do?
It provides practical helpers for working with HTTP requests in Symfony: validating incoming data, mapping request parameters onto typed objects, and centralising request logic that would otherwise sit in controllers. The goal is thinner controllers and reusable, service-friendly request handling. It is a convenience layer rather than a new HTTP abstraction.
Is jrm/request-bundle redundant with Symfony's MapRequestPayload?
Largely yes. MapRequestPayload and MapQueryString are mature first-party attributes on Symfony 7.2 and above, which is precisely the only range where this package installs. That makes the supported surface a strict subset of the range where the framework already solves the problem natively. The remaining risk is resolver priority ordering if both mechanisms are registered for the same argument.
Why did upgrading to 0.3.3 break my Composer install?
Release 0.3.3 dropped support for every Symfony version below 7.2, so projects on 7.0 or 7.1 that upgraded on a patch bump now hit a Composer constraint failure. Under 0.x semver a patch release conventionally signals a compatibility-safe change, and this one was not. Pin the package to an exact version and review the changelog before running composer update.
Is jrm/request-bundle safe to depend on in production?
Treat it as a small, early-stage dependency. It is a single-author project with one credited outside contributor, versioned at 0.x, and it follows an explicit latest-version-only policy that drops older Symfony branches without a major bump. That is workable for an internal tool but represents real upgrade risk for a long-lived service. If you adopt it, pin the version and expect to maintain a fork or fallback path.
What are the alternatives to jrm/request-bundle?
On Symfony 7.2 and above, use the built-in MapRequestPayload and MapQueryString attributes with the serializer. On older Symfony versions, including 6.4 LTS, write a small custom ArgumentResolver, which is roughly a hundred lines and avoids a third-party dependency entirely. For Laravel projects, use FormRequest or spatie/laravel-data instead, since this bundle does not apply.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource