Request Validator Bundle Laravel Package

Getting Started

First, a critical framing note: this is a Symfony bundle, not a Laravel package. Despite the "request validator" name, it hooks into Symfony's kernel.controller event and relies on Doctrine annotations plus Symfony's Validator component. composer require seferov/request-validator-bundle in a Laravel app will install, but nothing will wire it up — there is no service provider, no Kernel, no annotation reader, and no controller event dispatcher to hook into. If you are working in Laravel, the correct "first use case" is to skip this package entirely and use php artisan make:request StoreThingRequest, which is the idiomatic equivalent.

If you are in a Symfony codebase where the bundle is already installed, look first at:

1. Seferov\RequestValidatorBundle\Configuration\Validator / Validators — the annotation classes you'll be putting on controller methods.
2. The event subscriber that listens on kernel.controller — this is where the request params are read and handed to symfony/validator.
3. Resources/config/services.xml — to confirm the validator service and annotation reader wiring match your Symfony version.

Minimal usage is roughly: declare the constraints as annotations above an action, then let the bundle pull the named request parameter and validate it before your action body runs.

/**
 * @Validators({
 *   @Validator(name="email", constraints={
 *     @Assert\NotBlank(),
 *     @Assert\Email()
 *   })
 * })
 */
public function registerAction(Request $request)
{
    // only reached if validation passed
}

For a Laravel developer, the mental model translation is: "annotations on a controller action that behave like a FormRequest that lives in the docblock instead of a class." That should immediately tell you why it's a poor fit for modern Laravel — see the next section for the equivalent patterns you'd actually write.

Implementation Patterns

If you are actually on Symfony (the only supported path):

• Per-action validation declarations. Constraints are scoped to the action, which keeps validation next to the route. This is pleasant for small controllers but does not scale — once you have three or four actions with ten constraints each, the docblocks become unreadable and unsearchable.
• Constraint reuse via Doctrine annotations. You can reuse @Assert\* constraints and custom constraints you've already defined elsewhere in the app, so the bundle piggybacks on your existing validator configuration rather than introducing a parallel ruleset.
• Error surfacing is implicit. Validation failures need an exception listener or a response listener to translate violations into a 400/redirect. Check what the bundle does by default in your version before assuming — in most setups you'll write the failure handler yourself.

Laravel equivalents for the same day-to-day needs (recommended):

• FormRequest for controller-scoped validation. php artisan make:request, put rules() and authorize() on it, type-hint it in the controller method. This is the direct analogue of an annotated action, but it's testable in isolation, autocompletes in the IDE, and is discoverable via grep.
• Inline $request->validate([...]) for one-off endpoints. Cheapest option; fine for two or three rules.
• Custom Rule objects for reusable constraints. php artisan make:rule gives you passes()/message() — the Laravel equivalent of a Symfony ConstraintValidator.
• Conditional rules with Rule::when / Rule::requiredIf. Replaces the Symfony annotation "groups" concept for scenario-based validation.
• $request->validated() only. Never $request->all() after validation — this is the Laravel habit that most closely mirrors "the controller action only runs on valid input."
• prepareForValidation() for normalization (trimming, casting empty strings to null) before rules execute — the closest thing to intercepting the raw request params before they hit the validator, which is what the bundle does at the event level.
• API resources / exception handler. Laravel's ValidationException renders a 422 JSON response automatically for Accept: application/json — you do not need to build the response plumbing the Symfony bundle leaves to you.

Integration tips if you must keep the Symfony bundle: pin the bundle version explicitly ("seferov/request-validator-bundle": "1.x"), keep doctrine/annotations installed and the annotation reader enabled, and write a test around at least one annotated action so a Symfony upgrade that drops annotation support fails loudly rather than silently skipping validation.

Gotchas and Tips

• The framework mismatch is the headline gotcha. Nine stars, zero dependents, last release January 2022. Nothing in the Laravel ecosystem depends on it, so installing it buys you maintenance liability with none of the framework integration. Do not add it to a Laravel composer.json.
• Doctrine annotations are effectively deprecated. PHP 8 attributes are the modern form, and this package's last release predates broad attribute support in most bundles. On PHP 8.1+ with Symfony 6+, the annotation reader is opt-in and easy to forget — if validation silently never fires, that's usually why. Confirm the listener is actually invoked before debugging your constraints.
• Silent no-ops are the failure mode. Because validation is attached via annotations resolved at container compile time, a typo in an annotation class name or a missing use statement can result in no validation rather than an error. Add an explicit test that posts invalid data and asserts a 4xx — this is the single most valuable guard you can write.
• Low adoption means no safety net. With 0 dependents, there are no downstream CI matrices catching breakage on Symfony upgrades, no security advisories, and a bus factor of one. Treat it as vendored code: fork it or vendor it if you depend on it seriously.
• Debugging the event pipeline. If the browser gets a 500 instead of a 400, the problem is almost always the kernel.controller listener priority relative to other listeners (e.g. security, param converters) — check bin/console debug:event-dispatcher kernel.controller.
• Config quirks. Bundle registration in config/bundles.php is not automatic on Flex for abandoned/rare bundles; you may need to add it manually, and the annotation reader must be explicitly configured as a service if you've disabled framework.annotations.
• The right extension point is a fork. If you need PHP 8 attributes or Symfony 6/7 support, there is no plugin API worth using — the annotation classes are small and copying them into your app (or a one-file custom kernel.controller listener that reads attributes) is less work than patching the bundle.
• Bottom line for a Laravel developer: the package's idea — declare validation next to the route, fail before the action runs — is already the default in Laravel via FormRequest. Spend zero time integrating this bundle and instead invest in FormRequest, custom Rule classes, and prepareForValidation(), which give you strictly more capability with first-party support.