Fr Validator Symfony Laravel Package

Technical Evaluation

Architecture fit: This is a baseline assessment because no prior assessment exists. v0.1.0 is the first tagged release and provides Symfony Validator constraints for nine French-domain checks: NIR, RIB, SIREN, SIRET, IBAN, BIC, VAT, NAF, and Phone. That fits Laravel/PHP products that need French business-identifier, payment, payroll, tax, or contact validation. The strongest architectural value is not the checks themselves but the normalized failure contract: each constraint exposes the core library’s typed failure reason as both a message parameter and the violation code. A TPM can leverage that for localized user messaging, API error contracts, and validation-failure telemetry.

Integration feasibility: Medium. The release notes describe Symfony Validator constraints, not native Laravel Illuminate\Validation\Rule implementations. A Laravel team can likely use them through Symfony Validator directly or through custom Laravel rules that wrap the constraints, but that bridge is not confirmed by the release notes. Adoption should assume an adapter layer until proven otherwise.

Technical risk: Medium. The domain logic is narrow and well-bounded, but v0.1.0 signals pre-stable API expectations. Risks include missing Laravel-native integration, Symfony Validator version constraints, dependency drift on petroslabs/fr-validator, incomplete documentation for Laravel service-provider registration, unknown translation/message behavior, and unproven edge-case coverage across French territories and identifier formats.

Key questions: Does the package register a Laravel service provider or publish config? Does it provide Laravel validation rules, or only Symfony constraints? Which PHP, Laravel, Symfony Validator, and petroslabs/fr-validator versions are supported? How are violation codes and message parameters consumed in Laravel’s validator? Are messages translatable? What is the test coverage and maintainer support model? Are the nine checks strict-format only, or do they include checksum/registry validation? What is the license and security disclosure process?

Integration Approach

Stack fit: Good for Laravel/PHP applications with French-market requirements, especially onboarding, KYC, invoicing, payments, CRM, payroll, and supplier/customer master data. Fit is strongest where teams already accept Symfony components or are willing to add a thin Laravel rule adapter. It is weaker for teams that require only native Laravel validation primitives.

Migration path: Treat this as a greenfield pilot, not a migration from an existing package. Start in a non-production branch by wrapping the constraints as Laravel custom rules or by invoking Symfony Validator behind an application service. Keep existing validation rules in place until the package passes contract tests for all nine checks.

Compatibility: Validate Composer constraints before adoption: PHP version, Laravel version, Symfony Validator version, and the petroslabs/fr-validator version. Confirm behavior under Laravel’s validator lifecycle, including message rendering, attribute naming, nullable/empty-value handling, and violation-code propagation. Check whether French overseas formats and international IBAN/BIC/VAT variants are in scope.

Sequencing: First, run a dependency and license audit. Second, build a small adapter spike for one or two constraints in a Laravel test application. Third, add contract tests covering valid, invalid, empty, and boundary inputs for all nine checks. Fourth, verify message parameters and violation codes appear in API responses and logs. Fifth, pin the version, document the adapter, and roll out behind feature flags to a limited domain.

Operational Impact

Maintenance: Low code surface but non-zero dependency maintenance. The package sits on top of petroslabs/fr-validator and Symfony Validator, so upgrades must be coordinated across PHP, Laravel, Symfony, and the core validator. v0.1.0 should be pinned exactly or with a narrow constraint until the API stabilizes.

Support: Support risk is elevated by the first tagged release. There is no evidence yet of long-term support, Laravel-specific documentation, or a broad user base. A TPM should assign an internal owner and avoid making it a critical-path dependency without a fallback validation path.

Scaling: Runtime cost should be negligible for typical form/API validation. The operational scaling concern is failure volume and false positives/negatives, not throughput. Validation failures should be measured by constraint and violation code so product and support teams can distinguish user error from rule defects.

Failure modes: Likely failure modes include Composer version conflicts, missing Laravel integration, uncaught Symfony Validator exceptions, incorrect empty-value handling, locale/message rendering gaps, and domain false negatives from the core validator. Violation-code mapping can become a failure point if codes are not stable or not surfaced consistently through the Laravel adapter.

Ramp-up: Low for PHP developers familiar with Laravel validation; moderate for teams that need to learn Symfony Validator constraints and build the Laravel bridge. A short internal spike plus a documented adapter and test suite should be enough for a capable Laravel team, but broad adoption before v1.0 should be gated by contract tests and a fallback plan.