Request Validator Bundle Laravel Package

Product Decisions This Supports

• Framework fit check (blocking): Despite being filed under Laravel/PHP, this is a Symfony bundle (RequestValidatorBundle, controller annotations), not a Laravel package. Any Laravel roadmap item that lists it as a candidate should be closed — Laravel's native FormRequest already covers this job with zero added dependency.
• Build vs. buy: Signals point to neither buy nor adopt — build the thin validation layer in-house or use framework-native tooling. With 9 stars, 0 dependents, and a last release of 2022-01-12, there is no ecosystem proof, no maintenance signal, and no security-response path.
• Legacy Symfony audit: The one legitimate decision this informs is a tech-debt inventory item — is this bundle already present in an old Symfony ≤5.x service? If so, flag it for replacement with Symfony's MapRequestPayload / Validator attributes before the next PHP/Symfony upgrade, since annotation-driven controller config was deprecated and removed in modern Symfony.
• Pattern reference, not a dependency: Useful as a design input for how to declare request contracts next to controller actions (declarative validation, fail-fast 400s, centralized error shapes). Treat the repo as documentation of an approach, not as a library to ship.
• Roadmap impact: No capacity should be allocated. Adoption cost is near-zero in code but non-trivial in risk ownership — we would own the fork, the PHP 8.2+/8.3 compatibility work, and the security posture.
• Use cases it does not unlock: API gateway validation, public-facing form validation, multi-tenant request contracts, OpenAPI-driven validation — all require a maintained dependency with an active CVE channel.

When to Consider This Package

Consider only if all of the following hold:

• The service is Symfony ≤5.x with annotation-based controllers, and this bundle is already installed (i.e., we are evaluating removal, not introduction).
• The validation surface is small, internal-only, and not exposed to untrusted traffic at scale.
• We are willing to vendor/fork it and accept full ownership of maintenance, PHP-version compatibility, and security patching.
• MIT license compatibility is confirmed for our distribution model (it is permissive, so this is usually a formality).

Look elsewhere — decisively — if any of the following apply:

• Target framework is Laravel. This package will not work. Use FormRequest + $request->validate(), or a maintained community package if you need richer rule sets.
• Symfony 6.2+ / 7.x. Native #[MapRequestPayload], #[MapQueryString], and the Validator component supersede this entirely, with first-party support.
• You need maintenance guarantees: no release in ~3 years, zero dependents, single maintainer, no visible CI/security policy.
• Compliance or enterprise support is in scope: no vendor, no SLA, no disclosed vulnerability-handling process.
• You are standardizing a validation convention across teams: a 9-star, unmaintained bundle is a convention nobody will adopt or trust.

How to Pitch It (Stakeholders)

For executives (30 seconds): A small open-source PHP validation helper was surfaced as a candidate for our request-validation work. On review it is (a) built for Symfony rather than our Laravel stack, (b) effectively dormant — no release since January 2022, nine stars, zero projects depending on it, and (c) fully redundant with validation features already built into both Laravel and modern Symfony. Recommendation: do not adopt. We get the same capability from framework-native tooling at no cost and no added supply-chain risk. Action is a one-line catalog update, not a roadmap item.

For engineering leads: The bundle validates request parameters via controller annotations. That pattern is now superseded by first-class framework support in both ecosystems. Adopting it would mean owning a fork: PHP 8.2+/8.3 compatibility, annotation-to-attribute migration, and security response for a dependency with no downstream users to surface regressions. The only justified touchpoint is if this already exists in a legacy Symfony service — in that case, scope it as a planned removal ahead of the next framework upgrade, not a new integration.

Ask: No budget, no sprint capacity. Approve closing the evaluation and, if a legacy instance exists, approve a small tech-debt ticket to replace it with native validation.