Request Validator Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and the framing needs correcting. Despite the description line in the ticket, gepur-it/request-validator-bundle is a Symfony bundle, not a Laravel package. Its architectural contract assumes Symfony's HttpKernel (request/response lifecycle), EventDispatcher, DependencyInjection compiler passes, and registration via Kernel::registerBundles() plus config/bundles.php. None of these exist in a Laravel application. Laravel's request pipeline is middleware + service container + FormRequest, and the bundle's service wiring, extension class, and kernel-boot assumptions have no execution path there. A "Laravel adoption" is therefore not an integration — it is a port of whatever validation logic the bundle contains, if any is worth porting.

Integration feasibility — low. The only realistic paths are:

1. Do not adopt. Use Laravel's native Validator/FormRequest, which already covers the presumed use case (validating inbound request payloads, returning structured errors, authorization gating).
2. Cherry-pick semantics. Read the bundle for any opinionated behavior (e.g., a specific error envelope, per-route validator resolution, header/query coercion rules) and reimplement it as a Laravel middleware or a base FormRequest. Cost is low if the surface is small; the value is only the convention, not the code.
3. Standalone Symfony app. Only relevant if the consumer service is Symfony — in which case the question is "should we run this bundle in Symfony," which is a different ticket.

Pulling the bundle in as a Composer dependency and expecting it to function is not a viable option.

Technical risk — high, driven by maturity rather than code complexity. Signals: 1 star, 0 dependents, composite score 0.005, no evidence of CI, no downstream consumers to derisk it, and no visible release cadence. This is effectively an unaudited, unproven codebase. For a validation component — a trust boundary that sits in front of every write path — that is the wrong profile. Specific risks: unknown PHP/Symfony version constraints (a stale composer.json will conflict-lock our own dependency graph), no security disclosure process, no test coverage signal, and a single-maintainer bus factor. The MIT license is clean and permits forking, which is the mitigation if we go with option 2.

Key questions for the maintainer / spike:

• What does this bundle do that Symfony's Validator component or Laravel's Validator does not already do?
• Is there a stable tagged release, a supported Symfony/PHP version matrix, and a test suite?
• How are validation failures surfaced (exception type, HTTP status, response body shape)? Is it PSR-7, symfony/http-foundation, or custom?
• Does it validate only the body, or also query/headers/route params? Any content-type coercion (JSON vs form)?
• Is the repo actively maintained, and what is the mean time to merge on issues?
• Are there any consumers beyond the author's own applications?

Integration Approach

Stack fit — none as-is. Our stack is Laravel on the illuminate/* component set. The bundle targets symfony/*. There is no shared runtime.

Recommended path — evaluate-then-port, with "no" as the default.

1. Timebox a spike (≤1 day). Clone the repo, read the source end to end (~small codebase), and document exactly what validation semantics it enforces. Produce a one-page diff against Laravel's FormRequest behavior.
2. Decide on convention, not code. If the bundle encodes a request/response contract we want (e.g., RFC 7807 problem-details error bodies, a per-endpoint validator registry, declarative rules in config), reimplement it as a thin Laravel middleware plus a BaseFormRequest. This is typically 100–300 LOC and gives us full test coverage and ownership.
3. Reject the dependency. Do not add gepur-it/request-validator-bundle to composer.json. If the port is needed, attribute the source in a header comment per MIT and move on.

Migration path. None required — there is no existing state to migrate. For teams currently on Symfony who are evaluating this bundle, the migration question is moot; for our Laravel services, the "migration" is just the port in step 2, and it lands as net-new code.

Compatibility. Watch PHP version and any transitive symfony/* constraints if we ever vendor the logic directly. Since the recommendation is a reimplementation against Laravel's Validator, we inherit Laravel's supported PHP matrix and avoid version-conflict risk entirely.

Sequencing.

1. Spike + written semantic diff (owner: TPM + one engineer).
2. Go/no-go on reimplementation, scoped to the endpoints that actually need custom validation.
3. Build middleware/FormRequest + unit and feature tests.
4. Roll out behind a single route group, then widen.
5. Document the convention in the platform guide so it is not reinvented.

Operational Impact

Maintenance — the decisive factor. A 1-star, 0-dependent package has no community to catch regressions and no economic incentive for the author to keep pace with Symfony/PHP releases. Adopting it means we own it anyway; owning a fork of somebody else's unaudited code is strictly worse than owning our own small, tested implementation. The port in the Integration Approach is the cheaper long-run decision.

Support. No vendor, no SLA, no security contact, no changelog. Escalation path is "read the source." That is acceptable for a dev-only linting tool and unacceptable for a request-validation trust boundary.

Scaling. Negligible runtime concern — request validation is stateless, CPU-cheap, and horizontally scales with the app tier. The real scaling cost is cognitive: every new endpoint team must learn a bespoke validation convention that is not in Laravel's docs and not on Stack Overflow.

Failure modes.

• Silent pass-through: a validator that fails to bind on an unregistered route lets malformed payloads reach the domain layer. Port with explicit default-deny and coverage tests.
• Error-shape drift: inconsistent 422 bodies break client error handling and SDKs. Pin the response contract with contract tests.
• Dependency-graph lock: a stale symfony/* constraint blocks framework upgrades. Avoided by not depending on it.
• Bus factor: upstream goes quiet, we are the maintainers of record. Mitigated by forking into an internal namespace under MIT, though the recommendation remains to reimplement rather than fork.

Ramp-up. Low for any Laravel developer if we reimplement — FormRequest is standard knowledge. High if we adopt the bundle as-is, because onboarding requires understanding Symfony's kernel, DI, and event model purely to read a validation layer, which is disproportionate to the problem being solved.

Bottom line. Score 0.005 with 1 star and 0 dependents is the correct read: this is not a candidate for adoption in a Laravel codebase. Treat it as a design reference, extract any useful convention, implement it natively, and keep the dependency graph clean.