Nova Phone Field Laravel Package

Product Decisions This Supports

• Feature scoping for admin-side phone capture. The package adds a masked, country-code-aware phone input to Laravel Nova resources — lead forms, customer profiles, support tickets. It is back-office data-entry polish, not a customer-facing capability. Scope it as a small UX line item, not a "phone number support" epic.
• Build vs. buy vs. fork. MIT-licensed, one line to integrate, so it wins on day-one cost. But with 31 stars, zero dependents, and a release history consisting only of a 2019 Laravel 6.0 compatibility bump, the honest comparison isn't "package vs. nothing" — it's "package vs. ~60 lines of our own Nova field wrapping a maintained phone library." Framing it that way makes the three-year maintenance cost visible in the decision rather than surfacing it mid-sprint.
• Roadmap gate against our actual Nova version. The description claims Nova 4 support; every artifact says otherwise (last release 2019, compiled Vue assets from the Nova 2/3 era, single compat bump to Laravel 6). Treat the vendor claim as unverified marketing copy. The decision this drives is binary: on Laravel 6 / Nova 2 it's a trial-able convenience; on Laravel 7+ or Nova 4/5 it's a stop signal — a Composer resolution error is an answer, not an obstacle to bypass with --ignore-platform-reqs.
• Data-quality investment, decided in the same breath. The mask is cosmetic and client-side. The field does not validate, normalize, or guarantee E.164 storage. If phone numbers feed search, deduplication, CRM sync, or outbound dialing, then adopting this package commits us to a separate server-side normalization and validation step (e.g. propaganistas/laravel-phone behind a fillUsing() callback or mutator). Budget that work now — it is not optional scope.
• Risk acceptance recorded explicitly. Adoption should be logged as an accepted maintenance risk with a named owner, a compatibility-test gate against our exact Nova version, and a fallback plan for the next framework upgrade. Without those three, this isn't a decision — it's an unowned liability on the roadmap.
• Coverage commitments to sales/support. The country-code → mask map is hardcoded in the package's JS with no config file. Before anyone promises "supports international numbers" in a spec, verify the regions we actually sell into appear in that map. Adding a region means editing vendor code.

When to Consider This Package

Consider it only when all of the following hold:

• We are on the Laravel 6 / Nova 2 line — or we've already decided to fork and own the Vue component.
• The use case is internal back-office entry, where formatting improves operator speed and reduces inconsistent input.
• Server-side validation and E.164 normalization are being added independently; the field is a UI hint only.
• Phone data does not drive compliance, KYC, fraud checks, or customer-facing verification without separate controls.
• We can spike it against our real Nova version this week, watch the browser console for silent mask-binding failures, and pin versions.
• There is an assigned owner and a documented fork/patch path.

Look elsewhere when any of these are true:

• We are on Laravel 7+ or Nova 4/5 — the Vue 3 toolchain and pre-compiled assets will likely mount but silently fail to bind the mask.
• We need current-version compatibility guarantees, JS dependency security patching, accessibility review, or any support path.
• We need robust validation and normalization as first-class capabilities rather than a bolt-on.
• Phone numbers are customer-facing, compliance-sensitive, or a system-of-record field.
• The required country coverage exceeds the 2019 hardcoded mask map.

The preferred alternative in those cases: a thin custom Nova field over a maintained phone library (intl-tel-input, propaganistas/laravel-phone, giggsey/libphonenumber-for-php). Slightly more up-front effort, materially lower ownership cost over three years.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed add-on that formats phone-number input in our internal admin screens as the operator types a country code. It is cheap to try and could shave friction from lead management and support workflows. It is explicitly not a platform component: adoption is minimal, nobody else depends on it, and it has not seen substantive development since 2019 — the only change since then added Laravel 6 support. Its own README claims Nova 4 compatibility, which our engineering review could not corroborate. Recommendation: approve a short engineering spike, not a commitment. Adopt only if it works cleanly on our exact Nova version and we formally accept ownership; otherwise build a small internal field over a maintained phone library — marginally more up front, far less over three years.

To engineering: Treat v0.0.4 as a compatibility ceiling, not a revival — it confirms Laravel 6 and implies Nova 2.x only, with compiled Vue assets from the Nova 2/3 era. Plan for a fork rather than direct Composer adoption on modern stacks. Isolate the field behind a single resource helper so it's swappable, keep every bit of validation and E.164 normalization server-side, and assert on normalized values in tests — not masked strings, which will churn every time the bundled patterns change or we fork them. During the spike, check the browser console first: the classic failure is a component that mounts but never binds the mask, rendering as a plain text box. Normalize on write via fillUsing() or a model mutator so sorting and querying run against clean E.164, never the masked display string.