Multiparam Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy — settle it as "build." This package is a reference design, not a dependency. It solves one narrow, well-understood problem (binding several request parameters into a single typed controller argument), and the framework ecosystem has since absorbed that pattern natively. There is nothing here to purchase, license, or vendor.
• Roadmap input for API/DX ergonomics. The existence of this bundle — and its low adoption (16 stars, 0 dependents) despite solving a real annoyance — is evidence that boilerplate request handling is a persistent developer pain, but not painful enough to justify an external dependency. That's a signal to ship it as a small, native capability rather than a platform bet.
• Feature definition for "typed request binding." Concretely: let a controller action accept a value object/DTO and have the framework populate it from query string, route parameters, or body — with validation and type coercion. Candidate use cases: compound filters on list endpoints (?min_price=&max_price=&currency=), compound identifiers (/{tenant}/{slug}), search/filter query objects, and form-to-value-object mapping in internal admin tools.
• Dependency-risk triage. Archived, single-maintainer, zero dependents, annotation-driven (the Doctrine annotation reader path is deprecated in favor of PHP 8 attributes). Any existing internal usage should be logged as a migration item with a target removal date, not renewed.
• Prior-art citation in design docs. Useful as a one-paragraph "why now" reference when proposing our own argument resolver: it shows the idea has been attempted, that it failed to gain ecosystem traction as a third-party package, and that the correct home for it is the framework layer.

When to Consider This Package

Consider it only under a narrow set of conditions:

• You are maintaining a legacy Symfony 2.x/3.x application that already has this bundle installed and working, and the cost of removal exceeds the cost of leaving it pinned.
• The scope is a handful of controllers, the app is in maintenance mode, and there is no upgrade to a modern framework release on the roadmap.
• You have vendored or forked it and can accept ownership of the code yourself — treat the fork as first-party code with a named owner.

Look elsewhere (or build in-house) in essentially every other case:

• Greenfield work, or anything in a Laravel codebase. Despite being listed as a PHP package, this is a Symfony bundle built on Symfony's annotation/argument-resolution machinery. It is not designed for Laravel's container or request lifecycle, and forcing it in would cost more than the 20–40 lines it replaces.
• Anything with a support or security expectation. Archived status means no CVE response, no PHP-version compatibility work, and no fixes for annotation-parser deprecations.
• Any team counting on it as a dependency. Zero dependents and 16 stars means effectively no production usage to learn from — you would be the first serious adopter and would discover the edge cases yourself.
• Preferred alternatives: Symfony 6.3+ #[MapRequestPayload] / #[MapQueryString], or a custom ValueResolver; on Laravel, a FormRequest with a toDto() method, spatie/laravel-data, or a small middleware. All are supported, tested against current PHP, and cost roughly a day of work.

How to Pitch It (Stakeholders)

To executives: This is an abandoned open-source utility, not a vendor product. Recommendation: do not integrate, do not budget for it, do not add it to the approved dependency list. It is useful to us only as evidence — it confirms that developers find multi-field request handling tedious, and it confirms that nobody has successfully sold that as a standalone product. The takeaway for our roadmap is a small, low-risk internal improvement: roughly one to two sprints of engineering to let our API accept typed request objects directly. That reduces per-endpoint boilerplate and validation duplication across our services, which is a measurable velocity and defect-rate win, and it is entirely within our control.

To engineering: Treat it as prior art, not a dependency. The idea — resolve multiple request inputs into one typed argument — is sound; the implementation is a decade old, annotation-based (superseded by PHP 8 attributes), single-maintainer, and archived. Licensing is MIT, so we can read and borrow the concept freely, but we should write our own resolver against our current framework version. Proposed scope: a value resolver or DTO-binding layer, attribute-driven, with validation and coercion tests. If any service already has this package installed, flag it in the risk register and estimate the removal — it should be a low-effort swap to native handling given the tiny surface area.