- Is pixelavengers/extra-validator-bundle a Laravel package?
- No. It is a Symfony bundle built around Symfony's Validator component and bundle registration conventions. It will not auto-discover or register a service provider in a Laravel application. Treat it as a reference implementation, not a Laravel dependency.
- Can I install extra-validator-bundle in a Laravel app with Composer?
- You can attempt composer require, but expect dependency conflicts. The package targets Symfony components and older PHP constraints, so a dry-run against your Laravel and PHP versions will likely fail. Even if it installs, there is no Laravel service provider or config publishing.
- What validation rules does extra-validator-bundle actually provide?
- The useful surface area is a small set of Constraint and ConstraintValidator class pairs for common checks such as phone, number, or identity-format validation. The bundle wiring adds no value in Laravel; the rule logic is the only portable part. Enumerate the specific constraints you need before deciding anything else.
- How do I use extra-validator-bundle rules in Laravel?
- Do not try to register the bundle. Instead, read the constraint and validator classes, extract the rules you need, and reimplement them as native Laravel Rule objects via php artisan make:rule or as calls into a maintained library. Port only bespoke rules with no maintained equivalent, and add tests for format assumptions.
- Does extra-validator-bundle support Laravel 10 or Laravel 11?
- There is no evidence of Laravel support at all. The package is a Symfony bundle with Symfony 2.x-era structure, and its composer constraints are unlikely to resolve on modern Laravel stacks. Assume incompatibility until a composer require dry-run proves otherwise.
- Is extra-validator-bundle maintained and safe for production?
- It shows essentially no production evidence: 14 stars, 0 dependents, and a low score. The structure suggests it originated in the Symfony 2.x era and is likely abandoned. Adding an unmaintained dependency for a handful of validators is a poor supply-chain trade.
- Why is an unmaintained validator package risky?
- Validation rules for phone numbers, national IDs, tax numbers, and postal codes silently rot as formats and regulations change. An unmaintained validator implies correctness it no longer guarantees, which is worse than having no rule at all. Prefer actively maintained upstreams for commodity formats.
- What are maintained alternatives to extra-validator-bundle for Laravel?
- Use Laravel-native Rule classes for bespoke checks, and maintained libraries for commodity formats: giggsey/libphonenumber-for-php for phone numbers, egulias/email-validator for email, and maintained Laravel rules packages for IBAN or postal code. Symfony's own Validator constraints are an option only if you are actually running Symfony.
- Can I run Symfony's Validator component alongside Laravel's validator?
- Technically yes, but it is not a clean architectural fit. You would stand up a second validation stack, duplicate error handling, and add translation and integration overhead. For a Laravel-first codebase, porting the specific rules is simpler and lower risk.
- How should I evaluate or port extra-validator-bundle before using it?
- Start by enumerating the exact constraints your product needs; the list usually shrinks to two to five rules. Then review composer.json constraints, run a composer require dry-run against your PHP and framework versions, and check the last commit date. Map each rule to a product requirement, prune heavily, and port only the bespoke rules into first-party Laravel Rule classes with tests.