Nova Cpf Cnpj Field Laravel Package

Technical Evaluation

• Architecture fit: Narrow, single-purpose adapter over Laravel\Nova\Fields\Text that adds CPF/CNPJ masking and (likely) client-side validation to a Nova resource form. It is a presentation-layer convenience, not domain logic. The correct architectural home for CPF/CNPJ validation and normalization is the application layer (FormRequest, custom validation rule, or value object), not a Nova field. Treat this package as UI sugar only, and pair it with independent server-side validation regardless of adoption.
• Integration feasibility: Low effort — composer require, add the field to a Nova resource, optionally configure mask/format behavior. Realistic spike cost is 1–2 hours including verification. The gating question is version compatibility, not implementation complexity.
• Technical risk: High relative to delivered value. 1 star, 0 dependents, and a composite score of 0.105 indicate no meaningful community scrutiny or production evidence. Expect single-maintainer stewardship, dormant commits, and no CI/test signal. Nova fields are tightly coupled to Nova's major version (v4 → v5 broke field APIs); an unmaintained field is a predictable upgrade blocker. Low-scrutiny packages also carry supply-chain exposure — pin the version, review the source, and audit transitive dependencies.
• Key questions:
  • Which Nova and Laravel/PHP versions are supported by the Composer constraint? Is Nova 4/5 covered?
  • Does it validate (check-digit algorithm) or only mask/format? Is validation client-side only?
  • Is the persisted value raw digits or the masked string — and is that consistent and documented?
  • Does it expose a reusable server-side validation rule, or is validation duplicated?
  • License terms, maintenance status, and last commit date?
  • Is there a maintained alternative (e.g., a general PT-BR validator package plus a thin custom field)?

Integration Approach

• Stack fit: Only relevant if the target application runs Laravel Nova. Outside Nova this package has no role; the equivalent need is met by validation rules (geekcom/validator-docs, laravellegends/pt-br-validator) plus a front-end mask. Confirm Nova is actually in the stack before spending further evaluation time.
• Migration path: Given the adoption signals, the preferred path is vendor the field into the application namespace (copy the class, own it, add tests) rather than depend on upstream. This converts an unmaintained dependency into ~100 lines of owned code and eliminates upgrade risk at negligible cost. Adopting as a Composer dependency is defensible only for a short-lived spike.
• Compatibility: Build an explicit support matrix before merging: Laravel version × Nova version × PHP version. Verify the field renders and round-trips values on the exact Nova version in use. Confirm behavior in Nova's index/detail views, not just forms — formatting inconsistencies there are common.
• Sequencing:
  1. Confirm Nova version, PHP version, and whether CPF/CNPJ fields already exist.
  2. Spike in staging: install, render, submit, verify stored value format.
  3. Cross-check validation against the authoritative CPF/CNPJ check-digit algorithm with known-valid and known-invalid fixtures.
  4. Add server-side validation independent of the field (non-negotiable).
  5. Decide: adopt, fork, or implement in-house — default to fork/in-house.
  6. Only then roll to production resources.

Operational Impact

• Maintenance: Effectively zero upstream maintenance — budget for self-ownership. If vendored, maintenance cost is low and bounded; if consumed as a dependency, the team inherits the risk of a Nova upgrade with no upstream fix.
• Support: No community, no dependents, no issue-tracker gravity. There is no escalation path; internal engineers are the support tier. This should be an explicit, documented acceptance by the owning team.
• Scaling: No meaningful runtime scaling concern — formatting and validation are trivially cheap and per-request. The scaling risk is organizational, not computational: adoption of an unmaintained package across many Nova resources multiplies the eventual upgrade/removal cost.
• Failure modes:
  • Silent data quality failure: mask-only behavior accepts invalid documents, polluting downstream systems (billing, ERP, KYC).
  • Storage inconsistency: mixed masked/raw values across records break search, dedupe, and joins on the document field.
  • Upgrade breakage: Nova major upgrade leaves the field unusable, blocking the panel upgrade.
  • Dependency resolution conflict: stale Composer constraints block Laravel/PHP upgrades.
  • Abandonment: no security or compatibility patches; unpatched transitive dependencies.
• Ramp-up: Very low — hours for a Laravel/Nova-fluent engineer. The real cost is governance: the decision to own an unmaintained package, the server-side validation work that must accompany it, and the data-format standard that should be defined once and enforced everywhere.