mkoprek/request-validation-bundle
A validation bundle for PHP applications that applies rules to incoming HTTP request data, helping you reject malformed or missing input before it reaches your controllers. Define rules once and get consistent validation behavior and error responses across your request handling.
Architecture fit — the framework mismatch is now confirmed by evidence, not inference. The 3.0.1 release note states that a subscriber is now enabled only for /api paths. "Subscriber" in this context is Symfony's EventSubscriberInterface, registered against kernel events — the exact extension mechanism Laravel does not expose. This is no longer a naming ambiguity around the word "bundle"; the release note describes a change to Symfony's request/kernel event pipeline. Laravel has no kernel event subscriber registry, no bundle boot ordering, and no compiler passes. On a Laravel stack this package cannot be installed and used as designed. The distinction now moves from "resolve before further evaluation" to "resolved: no integration path."
Integration feasibility — low, and slightly lower than before. The new release does not add a service provider, facade, publishable config, or framework-agnostic core. What it does reveal is that validation is applied by a globally registered event subscriber whose activation is now gated on request path. That is precisely the kind of behavior a Laravel team would have to reimplement from scratch — Laravel's Validator is invoked explicitly from Form Requests or controllers, not by a subscriber watching the request lifecycle. The reusable asset remains the rule set, and a path-scoped subscriber adds a second thing to reverse-engineer rather than reducing the porting surface.
Technical risk — high, unchanged in category, with a new and specific concern: patch-level behavior change. The headline finding is not the scoping itself but that a material change in when validation fires shipped as 3.0.1. Under semver, a behavior change that can cause validation to stop running on previously covered routes belongs in a major or minor release with migration notes, not a patch. The note contains no rationale, no configuration reference, no mention of whether the path prefix is configurable, and no guidance for consumers validating web (non-/api) routes — who have, by implication, just lost validation coverage. Combined with a last substantive release in 2023-05-24, zero stars, and zero dependents, this reads as an unannounced behavior fix made without a consumer base to consult, which is itself the abandonment signal: no one was in a position to object.
Key questions for the author or source review:
/api prefix hardcoded or configurable? If hardcoded, this is a design narrowing, not a fix.Validator component does not already do?composer.json constraints for PHP and Symfony components?Recommendation: reject for adoption; retain as a code reference only if the rule set proves valuable. The 3.0.1 release does not improve the 0.06 score — it supplies independent confirmation that this is a Symfony kernel-integrated package and that its versioning is not a reliable signal of behavioral stability.
Stack fit. If we are on Symfony 6.4/7.x, the package is technically installable, and 3.0.1 arguably makes it more appropriate there by scoping the subscriber to API routes — but adoption risk is unchanged, and anyone upgrading across this version must audit which routes lost coverage. If we are on Laravel, there is no stack fit at all, and the honest framing is unchanged: "we are evaluating a rule specification, not a dependency."
Migration path. Three options, in ascending order of preference:
ServiceProvider, invoke it from middleware or Form Requests rather than a subscriber, publish config, map exceptions to Laravel's validation response format. Highest effort, permanent fork to maintain, and 3.0.1 shows the upstream behavior we would be forking is still moving.Validator rules or Form Requests. Bounded effort, no new dependency, idiomatic and reviewable, and immune to upstream path-scoping decisions.Compatibility. Unverified and likely adverse: PHP version floor/ceiling, Symfony component constraints, and absence of any Laravel constraint. Composer resolution against a current Laravel app is likely to conflict. Note that 3.0.1's subscriber scoping gives no compatibility signal either way — it does not indicate a Symfony 7.x compatibility commitment, and a package with no dependents has no pressure to make one.
Sequencing. Timebox a one-to-two day spike, unchanged in scope but with one addition: diff 3.0.1 against the prior version to establish exactly what the subscriber gating changed and whether the /api prefix is configurable. Output a one-page capability comparison against Laravel's native Validator, plus a one-paragraph note on the path-scoping semantics so it survives the spike. Gate the decision there. If the spike shows a thin Symfony wrapper — the most likely result, and now more likely — close the evaluation and fund a native implementation instead. Do not sequence this ahead of any committed roadmap item; a subscriber-scoping patch does not constitute adoption momentum.
Maintenance. Bus factor of one, no release cadence, no dependents generating patches. Every future PHP or framework upgrade becomes our problem to solve in someone else's code. The 3.0.1 release is a small counter-signal — the maintainer is not entirely gone — but a single narrow patch after roughly two years of inactivity is not a maintenance commitment, and it did not touch the compatibility surface that matters (PHP 8.3/8.4, Symfony 6.4→7.x). If we fork, we own it indefinitely; if we do not fork, we are one composer update away from being stuck.
Support. No commercial backing, no documentation ecosystem, effectively no community footprint. Zero dependents means zero Stack Overflow answers, zero blog posts, zero prior art. The 3.0.1 note is itself a support datapoint: a one-line change description with no migration guidance, published into the void. Anyone evaluating the upgrade must read the diff to learn what it means — which is the support model we would be adopting.
Scaling. Validation is CPU-trivial and will not be the bottleneck. The scaling question is organizational: an abandoned dependency in the request pipeline is a single point of forced migration that surfaces at the least convenient time. One scaling note now has a concrete answer: the bundle does register a global kernel event subscriber, and 3.0.1 narrows when it is active. Confirm the path match is evaluated cheaply and is configurable; treat performance as secondary to the coverage question.
Failure modes.
/api means any route outside that prefix is validated by nothing. If the gating is hardcoded, consumers validating web routes lose coverage with no exception, no log line, and no test failure — data integrity and potentially security exposure discovered in production.Ramp-up. The API surface is small enough to learn in hours, but the reverse-engineering cost is the real burden — undocumented behavior must be inferred from source, and 3.0.1 adds a new inference (route scoping semantics) that did not previously exist. Each inference needs a test to pin it. Budget for a written capability note as a spike deliverable so the knowledge survives the individual.
Net position: unchanged and marginally reinforced. The 3.0.1 release confirms Symfony kernel-event integration, hardens the "no Laravel path" finding, and introduces a fail-open coverage risk delivered under a patch version. Abandonment risk dominates with no compensating differentiation. Decline adoption, capture the rule set if it is useful, and revisit only if a maintained Laravel binding appears alongside real adoption signals.
How can I help you explore Laravel packages today?