relief_applications/symfony-request-validator-bundle
A Symfony bundle that validates incoming HTTP requests before they reach your controllers. Define constraints once and get consistent, structured validation errors for headers, query parameters, and payloads, keeping request handling clean and predictable.
Framework reality check first. This is a Symfony bundle, not a Laravel package. There is no ServiceProvider, no facade, no config/*.php publish tag, and no FormRequest integration. Dropping it into a Laravel app is not a config exercise — you would be porting the kernel event listeners into middleware and swapping symfony/validator constraints for illuminate/validation rules. That is a rewrite, not an integration. So "day-to-day leverage" only exists in a Symfony service; in Laravel, the day-to-day leverage is reading the source for design cues and then writing FormRequest classes.
If you are in a Symfony app, the minimal path:
composer require relief_applications/symfony-request-validator-bundle
Register it in config/bundles.php — confirm the exact FQCN from the autoload.psr-4 block in composer.json, since the vendor name (relief_applications) and the namespace (Blixit\...) diverge:
return [
Blixit\RequestValidatorBundle\RequestValidatorBundle::class => ['all' => true],
];
Only add config/packages/request_validator.yaml if src/DependencyInjection/Configuration.php exists. At this package's size it may not, in which case there is nothing to configure and skipping that step is correct.
Where to look first (read in this order, not the README's order):
composer.json — the symfony/* and php constraints are the single most important lines in the repo. Verify they cover your runtime before anything else.Attribute/ or Mapping/ directory — this is the actual public API. Whatever you annotate controllers with lives here.EventSubscriberInterface or referencing kernel.request / kernel.controller — this tells you when validation runs and what it does on failure (exception vs. response vs. error bag).DependencyInjection/ — whether a Configuration class exists, and what extension points it exposes.First use case. Take one controller action that currently does $request->request->get('email') plus a hand-rolled if (!$email) throw new BadRequestHttpException(...). That is the canonical target: declare the expected inputs and constraints, and have failures short-circuit to a 400. Validate one endpoint, assert the failure path returns 400 and not 500, then stop. If you cannot get a single endpoint green in under an hour, the package is not worth the integration cost — walk away.
Laravel equivalent for the same use case, since that is where this assessment actually lands:
class StoreUserRequest extends FormRequest
{
public function rules(): array
{
return [
'email' => ['required', 'email', 'unique:users,email'],
'name' => ['required', 'string', 'max:255'],
];
}
}
That covers 100% of what this bundle advertises, with first-party security patches and a hiring pool.
Declarative validation on the action (Symfony). The pattern this bundle exists for is co-locating constraints with the endpoint rather than in a separate form class. Expect something shaped like an attribute on the controller method that names the payload source (body, query, header) and the constraint set. The pattern to verify in the source: does it validate into a populated DTO you receive as a controller argument, or does it only assert and pass the raw Request through? The former is the reason to adopt; the latter is a thin guard you could write in 40 lines of middleware.
Failure handling as a single policy. The value of the bundle is that every endpoint fails the same way. Pick one behavior and enforce it project-wide — either let it emit a JSON error response with a 422/400, or catch a bundle exception in one kernel.exception listener and shape it. Do not mix: some endpoints returning the bundle's default error shape and others returning a custom envelope is how API consumers break.
Wrapping the dependency. Given the adoption profile (1 star, 0 dependents, single maintainer, namespace suggests a re-published fork of blixit/RequestValidatorBundle), do not let attributes leak into forty controllers. Define one internal interface — RequestValidator::validate(Request $request, string $dtoClass): object — and call that from controllers or a subscriber you own. If the bundle dies, you reimplement one class instead of touching every endpoint. The attribute syntax is the hardest thing to unwind later.
Laravel-side patterns that mirror the intent:
FormRequest for anything with more than two fields — authorization + rules + messages() in one class, auto-resolved by the container.$request->validate([...]) inline for trivial endpoints, so controllers stay one-liners.ApiFormRequest base with failedValidation() overridden to throw ValidationException with your JSON envelope — this is the Laravel equivalent of the bundle's "consistent error responses" feature, and it is five lines.php artisan make:rule) for domain checks — this maps to the bundle's "custom validators" extension point, but with framework support and test tooling.kernel.request listener, with the advantage that you can register it per-route group.Integration tip for a dual-framework org. If you genuinely run both Symfony and Laravel services, resist the urge to unify validation across them with a bundle. The bundle only helps the Symfony side, and the Laravel side gains a bespoke API no one else knows. Standardize on the framework-native validator in each; share a schema (OpenAPI, JSON Schema) if you need cross-service contract agreement.
The Symfony version constraint is the whole ballgame. A single-maintainer bundle with no release cadence almost certainly declares something like ^4.4|^5.0 and will not have been tested on Symfony 6.3+, let alone 7.x. Check this line before you write a single attribute. If it does not cover your version, stop — you are now maintaining a fork on day one.
Fails-open risk is the one that will bite you. Validation runs from a kernel event listener. If a Symfony upgrade changes listener priority or event ordering, the listener can stop firing and nothing errors — requests pass through unvalidated. Mitigate with a smoke test that posts a known-bad payload and asserts a 4xx, run in CI on every upgrade. Do not rely on unit tests of the validator class; test the full kernel path.
The README is probably stale. Read composer.json and the Attribute/ classes as ground truth. Attribute names in the README frequently drift from the actual class names on tiny packages, and autocomplete plus a composer dump-autoload will catch the mismatch faster than any doc.
Vendor-name / namespace mismatch. relief_applications/symfony-request-validator-bundle in Composer but Blixit\ in the source and blixit/RequestValidatorBundle upstream means this is a re-published fork with unverified divergence. Before adoption, diff it against upstream if you can find it, and confirm the license permits internal forking. If the delta is unclear, assume you own the code.
Pin the exact version, never ^. With no release cadence, a ^ range is a coin flip on the next composer update. Commit the lockfile and add the package to a quarterly review list.
No config class means no extension points. If DependencyInjection/Configuration.php is absent, you cannot inject custom validators, override the status code, or change the response format without forking. Confirm this exists before committing, because "configurable status codes and formats" is one of the bundle's advertised features and it is easy to assume it ships.
Error shape on failure is undocumented. Determine empirically whether failure is an exception (catchable in kernel.exception), a JsonResponse written directly (hard to intercept), or an error bag on the request. If it writes a response directly from the listener, your global exception handler will not see it, and every API consumer gets two error formats. Read the listener class to answer this in five minutes.
Empty payloads and content-type. Confirm behavior when the request body is not JSON, is empty, or is a JSON array rather than object. These are the cases that produce 500s instead of 400s, and the bundle's own test suite (if any) is unlikely to cover all three. Write those tests yourself against the endpoint.
In Laravel, this package is a non-starter — and that is the tip. Do not attempt a bridge package or a ServiceProvider shim. The dependency is on symfony/validator constraints and the HTTP kernel event lifecycle; the shim would be larger and more fragile than the validation code it replaces. The productive takeaway from reading this repo is structural: attributes on controllers are a nice ergonomic, and in Laravel you can get 90% of the way there with FormRequest resolution plus a ApiFormRequest base class, keeping the rules visible from the route signature without any third-party dependency.
Debugging tip. With no docs, add dd($request->all()) or a Symfony profiler breakpoint inside the listener's validate() to confirm it is actually being hit on the route you care about. Silence is ambiguous — it can mean "passed validation" or "never ran."
How can I help you explore Laravel packages today?