Pt Br Validator Laravel Package

Product Decisions This Supports

• Localization / market-entry scope: This package supplies Laravel validation rules for Brazilian documents and formats (CPF, CNPJ, CPF/CNPJ combined, CEP, phone/cellphone, UF state codes). It directly supports the product decision to ship a Brazil-ready onboarding, checkout, KYC, or registration flow instead of hand-rolling regex validation.
• Build vs. buy (buy/integrate): The alternative is maintaining in-house validation rules per form. Adopting an established, versioned package reduces the surface area your team owns — but a 13.0.0 major bump (no published changelog beyond a diff link) means you are also buying into a semver migration cycle.
• Data quality and fraud/friction trade-offs: Validating CPF/CNPJ format and check digits at the edge reduces bad records in CRM/billing and cuts failed downstream integrations (payment gateways, invoicing, ERP). This is a measurable input to conversion and support-cost decisions.
• Roadmap gating: For a Brazil launch, this is a low-effort enabler. Treat it as an enabler dependency, not a feature line item — but budget a small spike for the 13.x upgrade before committing dates.
• Compliance/audit posture: Document validation rules are policy-adjacent (fiscal invoicing, identity checks). A pinned, versioned, widely-used package is easier to justify in a security review than bespoke validators.

When to Consider This Package

Consider adoption when:

• The product serves Brazilian users and forms collect CPF, CNPJ, CEP, UF, or phone numbers.
• You are on a Laravel version still supported by the package's 13.x line — the major bump is the single most important compatibility question. Verify the required PHP and illuminate/* versions before committing.
• You want framework-native Validator integration (rule strings in Form Requests) rather than a separate service layer.
• You need check-digit correctness, not just string-format matching.

Look elsewhere or build in-house when:

• You need only a single, exotic rule — a two-line custom Rule class is cheaper than a dependency.
• You require CPF/CNPJ existence or status checks at the Receita Federal level; this package validates structure/check digits, not registry status. You will still need a paid API for that.
• You are not on Laravel, or you are on an older Laravel version outside the 13.x support window.
• Your compliance regime requires a vendor with a support contract/SLA — this is community-maintained OSS.

Release-specific caution (13.0.0): A major version bump with no human-readable changelog is a yellow flag. Treat it as potentially breaking until verified: diff the release, check for dropped PHP/Laravel support, renamed or removed rule aliases, and changed validation semantics. Pin to 12.2.x in production until the upgrade is tested in staging against real-world CPF/CNPJ fixtures.

How to Pitch It (Stakeholders)

For executives: We can ship Brazilian document validation in days rather than weeks by integrating a small, mature, widely-used open-source Laravel package instead of building and maintaining it ourselves. It improves data quality in registration, checkout, and billing, and reduces downstream failures with payment and invoicing partners. Cost is near zero in license terms; the real cost is a periodic upgrade cycle. The package just published a major version (13.0.0) without a written changelog, so we recommend staying on the current pinned version until we complete a short, low-risk upgrade verification.

For engineering:

• Adopt as a composer dependency with a pinned minor (e.g. ^12.2) in production today.
• 13.0.0 is a major bump with only a compare link — do a compatibility spike: confirm PHP/Laravel support matrix, scan for removed or renamed rules, and run existing form tests plus a fixture set of valid/invalid CPF and CNPJ samples.
• Keep validation at the Form Request / Rule layer so it stays swappable. Do not let package rule strings leak into domain models or API contracts.
• Document the upgrade runbook; expect this to recur on each major.

Recommendation: Approve adoption of the currently proven version now; schedule a timeboxed (≈0.5–1 day) evaluation of 13.0.0 before the next dependency refresh, not mid-sprint.