Pt Br Validator Laravel Package

Technical Evaluation

Architecture fit laravellegends/pt-br-validator is a thin, conventional Laravel service-provider package: it registers Brazilian document validation rules (CPF, CNPJ, CPF/CNPJ, and related BR-specific formats) directly into the framework's Validator facade via auto-discovery. It is a leaf dependency — no persistence, no queues, no config sprawl, no middleware. Architecturally it sits entirely inside the request/FormRequest validation layer, which is exactly where it should be. It composes cleanly with Rule:: objects and custom messages, and requires no changes to domain or persistence layers.

Integration feasibility Integration is a single composer require plus use of rule strings in existing FormRequest/$request->validate() calls. No migrations, no published config required for baseline use. The main feasibility question is version alignment with the host application's Laravel and PHP floors.

Technical risk The 13.0.0 release notes provided contain only a changelog diff link, with no enumerated breaking changes, deprecations, or features. That absence is itself a risk signal for a major semver bump: a major version in a Laravel package almost always encodes (a) a raised PHP minimum, (b) a dropped/added Laravel major constraint, or (c) behavioral changes to rule semantics or rule names. Until the diff is reviewed, treat 13.0.0 as unverified for production. Secondary risks: the package has a very small maintainer base (bus factor), relies on algorithmic validation rather than an external spec source, and its release cadence is tied to Laravel majors rather than to its own roadmap.

Key questions

• What are the minimum PHP and Laravel/illuminate/support constraints for 13.0.0, and which Laravel majors were dropped?
• Were any validation rule names removed or renamed, and are error message keys stable?
• Did validation semantics change — e.g. strict vs. masked input acceptance (punctuation in CPF/CNPJ), leading-zero handling, or rejection of repeated-digit placeholders?
• Does 13.0.0 add support for the upcoming alphanumeric CNPJ format, and does that change the public rule surface?
• Is 12.x now EOL, and is there a maintained security/patch branch?
• What is the test suite and CI coverage across supported Laravel/PHP matrix versions?

Integration Approach

Stack fit Strong fit for any Laravel application serving the Brazilian market: registration, KYC, checkout, and billing flows that must reject syntactically invalid CPF/CNPJ before hitting payment or identity providers. It is a poor fit if the organization standardizes on framework-agnostic validation or needs a documented compliance-grade document algorithm with an auditable spec trail — in that case a first-party implementation or a maintained enterprise validator is preferable.

Migration path

1. Keep the application pinned to 12.x in composer.json; do not float the constraint.
2. Create a short-lived branch with 13.0.0 and read the full compare/12.2.0...13.0.0 diff rather than relying on release-note prose.
3. Diff the rule registration surface (rule names, message keys, provider boot) against current usage.
4. Run the full test suite plus a fixture set of known-valid and known-invalid CPF/CNPJ samples, including masked input, to detect behavioral drift.
5. If the host app is not yet on the Laravel/PHP version 13.0.0 requires, upgrade the framework first — the package bump is not the vehicle for that change.

Compatibility Confirm the package's illuminate/support constraint against the app's Laravel version before anything else; a mismatch is the most common cause of a failed install here. Also audit other BR-market packages (e.g. payment SDKs, identity providers) that may themselves depend on an older 12.x constraint and create a resolver conflict.

Sequencing Treat this as a low-blast-radius, high-verifiability change: bundle the package bump into a regular dependency-maintenance window, not a feature release. Order: framework/PHP upgrade (if needed) → package bump → fixture-based validation regression → staging canary on registration/checkout paths → production. Keep the revert to 12.x trivially available; it is a one-line composer change.

Operational Impact

Maintenance Low ongoing effort by volume — the package has a small API and rarely needs code changes — but a predictable annual-ish touchpoint, since majors track Laravel majors. Budget one maintenance ticket per Laravel upgrade cycle. The real maintenance exposure is governance, not code: a single-maintainer project with no formal deprecation policy means major bumps can arrive with changelogs as terse as this one.

Support Community open source, no SLA, no commercial backstop. Given the tiny integration surface, the pragmatic mitigation is a documented exit path: the rules are a few dozen lines of algorithmic checks, so an internal fork or first-party reimplementation is a realistic fallback if maintenance lapses. That optionality is what keeps the vendor risk acceptable.

Scaling Effectively zero runtime scaling concern. Validation is pure in-process string/algorithmic computation with no I/O, no network calls, and no caching requirements; cost is negligible relative to request handling and is bounded by the number of document fields per request.

Failure modes

• Silent behavioral drift: a major bump changes which inputs pass (masked vs. strict, edge-case document numbers), causing legitimate users to be rejected at signup or checkout — the highest-severity failure, and the reason for fixture-based regression tests.
• Resolver conflict: a transitive dependency pins the old major, blocking upgrade or forcing a cascade of bumps.
• Framework version coupling: upgrading the package forces a Laravel upgrade, or vice versa, coupling two changes that should be independent.
• Abandonment: no release for a new Laravel major leaves the app stranded on an unsupported framework version, at which point the fork contingency must be exercised.

Ramp-up Minimal. Any Laravel developer can integrate and reason about this package in under an hour; the documentation burden is limited to which rule name covers which document type and how masked input is handled. The only specialist knowledge required is Brazilian document format rules, which matters for reviewing the fixture set rather than for day-to-day use.