Validation Bundle Laravel Package

Getting Started

Start by understanding what this package is: toshY/validation-bundle is a Symfony bundle, not a Laravel package. It hooks into Symfony's Kernel and DI container, registers services via config/packages/, and ships a *Bundle class that must be added to config/bundles.php. None of that machinery exists in Laravel, so there is no composer require + php artisan vendor:publish path here.

What a Laravel developer should actually do first:

1. Read the underlying source, not the bundle registration. A bundle is usually a thin Symfony wrapper around standalone components (most likely the Symfony Validator / constraints). The reusable parts live in src/ — the constraints, validators, and any custom rule logic.
2. Check whether you already have equivalent functionality. Laravel's own Illuminate\Validation covers a huge amount of ground, and Laravel 11/12 already pulls in symfony/validator transitively via the framework. Confirm you aren't about to duplicate what Rule, ValidationRule, or the Validator facade already give you.
3. If you only need the rules/constraints, extract them: install symfony/validator directly, instantiate Symfony\Component\Validator\Validation::createValidator() in a service provider, and register the constraints manually — the bundle registration step disappears entirely.
4. First real use case in a Laravel app: mirroring one of this bundle's domain constraints (e.g. an IBAN / postal code / identifier check) as a Rule object, then validating through Validator::make() like any other rule. This is where the "leverage" is — not in the bundle, but in borrowing its constraint implementations.

The first thing to check in the repo is composer.json: if the require block pins symfony/*: ^8.0 only, you may be forced onto Symfony 7.x-compatible tags for use with older Laravel versions that ship Symfony 6/7 components.

Implementation Patterns

Because this isn't a Laravel-native package, integration patterns fall into three buckets.

1. Drop-in constraint reuse (most common). Copy or composer require only the pieces you need and register them as Laravel rules:

// app/Rules/Iban.php
class Iban implements ValidationRule
{
    public function validate(string $attribute, mixed $value, Closure $fail): void
    {
        $validator = Validation::createValidator();
        $violations = $validator->validate($value, [new \App\Vendor\Constraints\Iban()]);

        if (count($violations) > 0) {
            $fail($violations[0]->getMessage());
        }
    }
}

Wire this into a RuleSet or use it inline via 'iban' => [new Iban()].

2. Standalone Validator service binding (for teams that want Symfony's constraint ecosystem in Laravel). Bind a shared validator instance in a service provider:

$this->app->singleton(ValidatorInterface::class, fn () => Validation::createValidator());

Then inject it into form requests and map violations to Laravel's MessageBag. This gives you access to Symfony's full constraint library (Luhn, IBAN, ISBN, UUID, ULID, currency, locale, etc.) that Laravel doesn't ship out of the box.

3. Translation/attribute bridging. Symfony constraints use annotations/attributes and a translator. If you use the attribute-based constraints, ensure you've configured a translator and that messages resolve through Laravel's lang/ files (or let them stay in Symfony's domain — usually fine, since the messages are English defaults).

4. Cross-framework validation layer in a monorepo. If your team runs Symfony services and Laravel services side-by-side, this bundle is the Symfony side of a shared validation contract. Adopt the constraint names/attributes consistently on both sides so DTOs can share meaning — but don't try to share the bundle itself.

Gotchas and Tips

• Package type mismatch. type: symfony-bundle in composer.json will not auto-register anything in Laravel. Bundle classes require Symfony\Component\HttpKernel\Bundle\Bundle and are wired through Kernel::registerBundles(). Don't expect php artisan about to show it.
• Symfony 8 = PHP 8.4 minimum. Symfony 8 requires PHP ≥ 8.4. Laravel projects still on PHP 8.2 or 8.3 cannot install the 2.2.0 line even if you only pull in the transitive constraints. Stay on the 2.1.x tag or vendor a copied constraint to avoid the constraint resolution fight.
• Constrain to the right tag. If you composer require toshy/validation-bundle in a Laravel app just to borrow constraints, Composer will try to install the full bundle (including Symfony kernel deps you already have via Laravel, possibly at incompatible versions). Prefer extracting the code, or add an explicit "symfony/framework-bundle": "conflict" in the root composer.json if you must vendor it.
• Translation domain. Symfony constraint messages live in the validators translation domain. Laravel's translator won't know that domain by default — expect untranslated English messages unless you copy the .xlf files into Laravel's lang/ tree.
• Attribute vs. annotation. Release 2.x has moved toward attributes; older constraint usage via annotations will not work on newer PHP without an annotation reader (which Laravel doesn't ship). Use PHP 8 attributes if you copy constraints.
• Service container isn't compiled in Laravel. Anything in the bundle that relies on ContainerBuilder compiler passes (tagged services, !tagged_iterator, etc.) will silently not be available. If you copy code that depends on tags, you must replicate the wiring manually in a service provider.
• Debugging tip: if a constraint validates fine in Symfony but fails in Laravel, check locale — Symfony's constraints sometimes branch on translator locale for message selection, and the default en in Laravel may differ from your configured Symfony locale.
• Extension point worth knowing: Symfony's ValidatorBuilder (accessible via Validation::createValidatorBuilder()) is where you register custom validators without the bundle. That single line is the entire value the bundle's DI configuration would otherwise give you.
• Version-compat matrix: 2.2.0 targets Symfony 8. If you're on Laravel 10 (Symfony 6.4 components) or Laravel 12 (Symfony 7.x components), stay on 2.1.1 unless you've tested the extracted constraints in isolation. There is no Laravel adapter in this package's history, so this is not a "waiting for Laravel support" situation — it will never "just work."

Bottom line for a Laravel shop: treat this as a source of reusable constraint implementations, not an installable package. Add it to your "look here for validation rules we don't have" list, keep an eye on the 2.2.0 PHP 8.4 floor, and vendor/extract rather than require.