Nova Cpf Cnpj Field Laravel Package

Product Decisions This Supports

• Brazil market entry / localization roadmap: If your admin workflows are built on Laravel Nova and you serve Brazilian customers, CPF (individual) and CNPJ (company) capture is table stakes. This package lets you add a formatted, validated tax-ID field to Nova resources without custom field work — a small enabler for a larger localization initiative.
• Build vs. buy for form primitives: The scope here is narrow (mask + validation for two document types in a Nova admin panel). It's a useful benchmark for deciding whether a thin localization primitive is worth a dependency versus a ~half-day in-house implementation. For most teams, this is squarely in "build it yourself or vendor it" territory, and the answer usually depends on how many Brazilian identifiers you'll need to support.
• Back-office onboarding and KYC-adjacent flows: Supports decisions about where tax-ID validation lives — at the Nova admin layer versus in the domain/API layer. Prefer the domain layer for anything customer-facing; use this only for operator-entered data.
• Roadmap scoping for compliance/data-quality features: If CPF/CNPJ normalization and checksum validation are recurring asks across products, this package clarifies the minimum viable behavior (mask, format, digit validation) so you can scope a shared internal solution rather than repeating field-level work.
• Use cases: internal ops panels for Brazilian entities, customer-support tooling where agents correct or enter tax IDs, vendor/partner records in a Nova admin.

When to Consider This Package

Adopt only when all of the following hold:

• You are on Laravel Nova and specifically need CPF/CNPJ input in Nova resources — this field has no value outside Nova.
• Your need is internal/admin-only, where a mask and checksum validation are sufficient and you are not building on top of it for programmatic validation elsewhere.
• You have verified compatibility with your Nova and Laravel/PHP versions. With 1 star, 0 dependents, and no visible maintenance signal, treat version support as unproven and time-box a spike.
• You are comfortable vendoring or forking it if upstream goes quiet — the surface area is small enough that this is realistic.

Look elsewhere (or build in-house) when:

• You need validation in APIs, imports, or customer-facing forms — you want a domain-level rule or a maintained validation library (e.g., a Laravel validation rule package) rather than a Nova UI field.
• You need broader Brazilian localization (CEP, CNPJ alfanumérico, IE, phone formats) — one narrow field won't compose into a strategy.
• Your compliance posture requires maintained, audited dependencies; single-star, zero-dependent packages are a supply-chain and bus-factor risk.
• You're not on Nova — Nova is a paid product; confirm licensing and version alignment before scoping.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost component that removes a friction point for Brazilian operations — operators can enter and validate CPF/CNPJ correctly in our admin tooling instead of relying on manual checks. It's not a strategic bet; it's a tactical accelerator for Brazil-facing back-office work.

For engineering: A narrow Laravel Nova field providing masked, validated CPF/CNPJ input. The trade-off is explicit: near-zero integration effort versus a dependency with essentially no adoption, no dependents, and unclear maintenance. Recommendation — evaluate with a short spike against our Nova/PHP versions, and plan to vendor or reimplement (the logic is small) rather than rely on upstream. Keep customer-facing and programmatic validation in the domain layer, and treat this as an internal-admin convenience only.