Param Converter Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow, for request-to-object mapping. This package sits in the same problem space as Laravel's route model binding, form requests, and custom route bindings — converting raw request input into typed objects before it reaches the controller. The decision it informs is whether to standardize that pattern in-house or adopt a third-party layer.
• Ecosystem fit check — the first decision it forces. Despite being framed here as a Laravel/PHP package, this is a Symfony bundle (*Bundle naming, "param converter" is a Symfony/SensioFrameworkExtraBundle concept). For a Laravel roadmap this is a non-starter; for a Symfony codebase it belongs in the "replace deprecated ParamConverter annotations" migration conversation, not the feature roadmap.
• Deprecation/replatform work. If the team is on Symfony and still using annotation-based param converters, the native replacement (ArgumentValueResolver, #[MapEntity], #[MapRequestPayload]) already exists in modern Symfony. This package is at best a stopgap, not a strategic dependency.
• Internal convention definition. Useful as a reference implementation when writing our own binding/resolution conventions — read the source, don't ship the dependency.
• Not a roadmap input. Zero stars, zero dependents, zero dependents-of-dependents means there is no user signal to react to. Nothing here justifies sequencing work.

When to Consider This Package

Consider it only when all of the following hold:

• The codebase is Symfony, not Laravel — confirm before anything else.
• You have legacy controllers using param-converter annotations and a migration window measured in weeks, not quarters.
• You have an engineer who will read the full source (it is small; that is the only thing in its favor) and accept ownership.
• The license is verified compatible and the code is vendored or forked into your repo, so an abandoned upstream cannot break a deploy.
• The mapping logic you need is genuinely bespoke enough that native resolvers would require more custom code than this saves.

Look elsewhere — or use the framework — when:

• You are on Laravel. Native route model binding, form requests, and Route::bind() cover this with zero dependency risk. This is the default answer.
• You are on Symfony 6.2+. Native attributes and value resolvers supersede the param-converter pattern.
• You need documentation, support, an SLA, a security response process, or a maintenance guarantee. At 0 stars / 0 dependents there is no community to catch a regression and no upstream obligation to patch one.
• Supply-chain review is a gate. An unmaintained package with no dependents is a standing liability; the "last release 2026-10-26" timestamp is also a data-quality flag worth resolving before anyone treats release cadence as evidence of health.
• The opportunity score (15.39) is your only quantitative signal, and it is low. That is not a mandate.

PM recommendation: Do not add as a dependency. Timebox a half-day spike to read the source and extract the pattern into our own resolver. Adopt only under the fork-and-own condition above.

How to Pitch It (Stakeholders)

To executives: This is not a product or a vendor relationship — it is a small, unmaintained utility with no users, no support, and no track record. Adopting it costs no money but does transfer all maintenance and security risk to us. The honest framing is: "There is a known pattern here that we can implement ourselves in about a day; buying it saves us that day and costs us indefinite ownership of someone else's abandoned code." The business case for adoption is weak; the business case for spending a day on our own version is strong.

To engineering: Two things to settle before any code is written. First, confirm the target framework — this is a Symfony bundle and does not apply to a Laravel service; if the ask came from a Laravel team, the answer is native route model binding and this conversation ends. Second, if we are on Symfony, the param-converter pattern is already superseded by native value resolvers and attributes. Treat this repo as documentation of an approach, not a dependency: read it, write our own twenty-to-forty-line resolver, test it, own it. If someone insists on the package itself, it gets vendored, not required.

To the requesting team: You will get the capability you asked for. You will not get it by adding a zero-star dependency to composer.json.