Validation Bundle Laravel Package

Getting Started

Expect friction before productivity. This is a Symfony 2-era bundle with no release since Nov 2019 and zero dependents, so budget 15–30 minutes for install and smoke-testing before you write any real code.

1. Install and pin. composer require tuxone/validation-bundle — if it fails on modern PHP, check the require block first; Symfony2 bundles often declare php: >=5.3 and symfony/symfony: ~2.x, which Composer will refuse to resolve. Pin exactly ("tuxone/validation-bundle": "dev-master" or the tagged version) and commit the lock file.
2. Register the bundle only if it has a DI extension. Look for DependencyInjection/*Extension.php and Resources/config/services.yml. If they exist: AppKernel.php (new Tuxone\ValidationBundle\TuxoneValidationBundle()) on Symfony 2/3, or config/bundles.php on Flex. If the bundle is constraint-only (just Constraint/ and Validator/ classes), you can skip registration entirely — PSR-4 autoloading is enough.
3. Read Constraint/ first. That directory is the entire public API surface. Each constraint class's public $message and constructor options tell you what it validates and how to configure it. Skim one Validator/ counterpart to see the failure semantics before trusting it.
4. First use case: apply one constraint to a single entity property with annotations and validate it in isolation via $validator->validate($entity) — not inside a full form — so you can confirm the constraint fires and the message renders. Then wire it into a Form constraints option.

If you cannot get a trivial constraint to fail a bad value within that first hour, stop and evaluate native Symfony constraints instead; there is very likely overlap.

Implementation Patterns

Constraint composition. Treat these as additive to Symfony's built-ins, not replacements. Stack them alongside NotBlank/Length in a sequence so format checks run after presence checks, and keep the bundle's constraints as the domain-format layer:

/** @Assert\NotBlank
 *  @Assert\Length(max=32)
 *  @CustomAssert\...  // bundle constraint
 */
protected $code;

Use them in Form types, not just entities. Putting the bundle constraint in the FormType constraints option keeps validation rules next to input definitions and avoids polluting the entity — useful when the same entity is validated under different rulesets.

Validation groups. Symfony2-era constraints often lack groups support in their constructors. If you need them scoped, either subclass the constraint to add groups or wrap the check in a custom Callback/service-level validator.

Validators as services. If a bundle validator needs a repository, HTTP client, or config, it will not be autowired by default in old bundles. Register it yourself and tag it:

app.validator.custom:
    class: Tuxone\ValidationBundle\Validator\SomeValidator
    arguments: ['@doctrine.orm.entity_manager']
    tags: [{ name: validator.constraint_validator, alias: some_alias }]

Then reference the alias from the constraint's validatedBy().

Unit-test each constraint you adopt. Use ConstraintValidatorTestCase (Symfony) to assert both pass and fail paths. This is the cheapest insurance against a stale regex or deprecated API silently passing bad data — critical when there is no community backing.

Isolation tactic. Because the bundle is unmaintained, keep every usage behind a single wrapper: one App\Validation\DomainConstraints collector class or a small set of app-level constraint classes that delegate to the bundle. When you eventually replace it, you edit one file.

Gotchas and Tips

• It is effectively abandoned. Last release 2019, 5 stars, 0 dependents. Assume no fixes. Fork it into vendor-free app code (src/Validation/) if you depend on it heavily; a 500-line bundle is cheaper to own than to fight.
• Symfony version skew is the main hazard. Symfony2 constraint validators commonly override setDefaultOptions() (removed in 2.7, replaced by configureOptions()) and call getTargets() with deprecated constants. On Symfony 4+, these either fail loudly or are silently ignored — the latter is worse, because the constraint passes everything. Test a deliberately invalid value on every constraint you adopt.
• composer require may need --ignore-platform-reqs. Do not leave that flag in CI. Fork and fix the composer.json instead.
• PSR-0 vs PSR-4. Old bundles sometimes use PSR-0 with Tuxone\ValidationBundle mapped to a non-standard path. If classes aren't found after dump-autoload, check the autoload block, not your namespace spelling.
• Annotation alias. The README (or Resources/config/validation.xml) defines the annotation alias. use Tuxone\ValidationBundle\Constraint as CustomAssert; is the usual pattern — don't assume the short name matches the class name.
• Messages won't be translated unless the bundle ships a Resources/translations/validators.*.xlf. Override messages in config/validator.{locale}.yml or pass explicit message options rather than editing vendor files.
• Property paths on nested objects. Hand-rolled validators frequently build ConstraintViolation with a flat setPropertyPath() instead of using the ExecutionContext path builder, which breaks AtPath/form error mapping on embedded objects. Verify with a nested form before shipping.
• Empty-value handling. Well-behaved constraints skip null and '' (to compose with NotBlank). Old validators often don't — meaning '' fails a format regex and you get duplicate errors. Check the top of validate() for an early return.
• Debugging tip: if a constraint never fires, first check validatedBy() resolves to an existing class, then check the validator is actually instantiated (dump() in the constructor). A missing validator.constraint_validator tag is the most common cause of silent no-ops.
• Extension point: when a rule is almost right, subclass the bundle's validator, override the single method that does the check, and register your subclass under the same tag alias — cheaper than rewriting, and keeps the fork surface small.