Nova Phone Field Laravel Package

Product Decisions This Supports

Back-office data quality as a product surface. Phone numbers are one of the highest-entropy fields in any CRM or admin panel. The same contact arrives as +55 11 91234-5678, (11) 91234-5678, or 11912345678. A country-code-aware mask nudges operators toward a consistent shape, reducing reconciliation work for support, sales ops, and anyone reporting on contact records. This is a quiet, compounding win rather than a headline feature.

Build vs. buy for Nova admin tooling. This is a micro-dependency, not a platform bet. The realistic alternative is 1–3 engineering days to build a custom Nova field; this package collapses that to roughly half a day of integration. For internal tooling with low blast radius, that trade is usually correct — provided the license question is resolved first.

Internationalization and multi-country launch readiness. Directly relevant if the roadmap includes LATAM, EU, or other markets where phone formats differ materially. It upgrades phone capture on existing resources without a form-builder migration or a redesign.

Use cases. Sales/CRM contact records, lead intake, order and shipping contact capture, KYC/onboarding flows — any Nova resource where a human types a phone number.

Scope boundary to decide deliberately. This package handles presentation (masking and formatting), not canonicalization. It informs, but does not settle, the data-model decision about how phone numbers are stored. Make that decision explicitly — store E.164 in a string(32) column and normalize server-side — rather than inheriting it from a field plugin.

When to Consider This Package

Consider it when:

• You are already running Laravel Nova (v4/v5) and are adding a phone field to one or more resources.
• Operators enter numbers across multiple countries, and inconsistent formatting is a known complaint from ops or support.
• You want a small, self-contained field the team can read end-to-end in an afternoon and vendor if necessary.
• The requirement is UX polish in an internal tool — not compliance-grade telephony validation.

Look elsewhere when:

• You are not on Nova — this has no value outside that ecosystem.
• You need authoritative validation and parsing. Use giggsey/libphonenumber-for-php at the model/validation layer; a client-side mask is not a validator and will accept structurally plausible nonsense.
• E.164 canonical storage is a hard requirement. Masking does not normalize; you still need a parse-and-store step server-side.
• License compliance is a gate. The NOASSERTION designation means no clearly declared license. For commercial or redistributed products, treat that as a legal-review blocker until resolved in writing. Internal-only use is an easier conversation, but still get it documented.
• Dependency health matters to your team. Zero stars, zero dependents, single maintainer, no published test suite — accurate signals of no community, no third-party battle-testing, and no realistic expectation of upstream fixes.
• Accessibility or browser compatibility is under formal review. Assume no a11y audit and no cross-browser test matrix exists; you own that verification.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost UX upgrade to our internal admin panel that improves how we capture customer phone numbers across the countries we operate in. It reduces the manual cleanup that currently follows inconsistent data entry, and procurement cost is effectively zero. Two honest caveats: it is an unproven, single-maintainer open-source component with no declared license, so I recommend treating it as internal-only tooling and vendoring the code rather than depending on it strategically. And it improves how numbers look; it does not by itself guarantee they are valid. If phone data quality becomes a business requirement — for messaging, KYC, or dedupe — we should budget a separate server-side validation and normalization task.

For engineering: One Nova field class, drop-in on existing resources, with the mask selected dynamically from the country code the user enters. The integration surface is deliberately tiny, which makes it easy to fork and own. Three things to plan for: (1) pin an exact version or vendor the package — do not rely on upstream maintenance, and read LICENSE before it touches anything customer-facing or redistributed; (2) pair it with a server-side parser so stored values are E.164-normalized and validated, since the field is formatting-only and the posted value is untrusted; (3) keep all field construction behind a single phone() helper in your own code so a swap-out is a one-method edit. Budget roughly half a day to integrate, plus smoke-testing on the exact Nova major you run — specifically paste of a full international number into an empty field, editing an existing record and changing one digit, and multiple phone fields on one form (mask libraries that register a global singleton often break here). Also budget the validation layer you likely want anyway.