Cpf Cnpj Laravel Package

Product Decisions This Supports

• Data quality in Brazilian back-office flows. CPF (individual) and CNPJ (company) are the identifiers that gate customer/supplier registration, invoicing, and KYC. This package is a Laravel Nova form field that formats/masks and validates those numbers at the point of data entry — a narrow but real lever against garbage tax IDs in the CRM/ERP.
• Scoping an admin-tooling decision, not a product decision. It only applies if you already run Laravel Nova (a paid admin panel). It does nothing for customer-facing signup, checkout, or mobile forms — those need their own validation/masking strategy. Treat this as an internal-ops line item, not a roadmap feature.
• Build vs. buy (really "borrow"). The core is the public CPF/CNPJ check-digit algorithm — roughly a few dozen lines of well-documented logic. Adopting a zero-star, zero-dependent package is effectively borrowing code with a maintainer attached. The honest framing: the decision is whether to vendor the rule into your codebase versus take a dependency.
• Use cases it enables: sales-ops and support consoles where agents key in tax IDs, supplier onboarding screens, billing/invoice prep screens, and any Nova resource holding a cpf_cnpj column with a unique/format constraint.
• What it does not decide: fiscal integration (SEFAZ, NF-e), tax-ID enrichment/lookup against Receita Federal, or deduplication of entities by tax ID. Don't let a field package get conflated with a compliance program.
• Roadmap signal: if Brazil is a target segment, this is a low-cost enabler for internal tooling — a checkbox, not a differentiator. Budget the real effort for the customer-facing path and for the upcoming alphanumeric CNPJ format, which is a genuine roadmap item for anything storing CNPJ.

When to Consider This Package

Consider it when:

• You already license Laravel Nova and Brazilian entities exist in your admin resources.
• The need is internal, low-blast-radius, and speed matters more than dependency hygiene — a day of work compressed into a composer require.
• Your team is willing to pin the version, review the source, and fork it if the maintainer goes quiet.
• You want masking and check-digit validation in one field type rather than writing a custom Nova field plus a validation rule.

Look elsewhere (or vendor the logic) when:

• You aren't on Nova. Then this is simply irrelevant — reach for a Laravel validation-rule package or a custom Rule object instead.
• Adoption signals matter to you. Zero stars, zero dependents, zero score means no community vetting, no visible test/security posture, and a single-maintainer bus factor. For anything touching invoicing or regulatory data, that's a documented-risk item your security review will flag.
• You need customer-facing quality. Client-side masking, phone-keyboard behavior, paste-normalization, and accessibility aren't Nova field concerns.
• You need forward-compatibility. Any CPF/CNPJ library that predates the alphanumeric CNPJ transition is a latent rewrite; verify explicitly rather than assuming.
• You need more than validation. Lookup/enrichment, normalization pipelines, or bulk cleansing of existing records are out of scope here.
• You have audit/provenance requirements (SOC 2, regulated fintech) that require reviewed, maintained dependencies.

How to Pitch It (Stakeholders)

To executives: "A free add-on for our internal admin panel that stops invalid Brazilian tax IDs from being saved — small, contained, and cheap. It's a convenience, not a strategic dependency: no adoption base, one maintainer. I recommend we pilot it in the admin only, or spend half a day copying the validation logic in-house so we own it. Either way it doesn't touch the customer experience or our roadmap."

To engineering: "One Nova field, drop-in, does masking plus check-digit validation. Caveats: unmaintained and unaudited — zero stars, zero dependents. Pin the version, read the source, add tests around the field, and confirm it handles the alphanumeric CNPJ format before we commit to it. If it's less than a day to extract the validation rule into our own app/Rules directory, prefer that."