Phone Number Laravel Package

Technical Evaluation

Architecture fit. This is a Laravel Nova field package, not a general phone-number library. Its blast radius is the back-office admin panel only — it does not sit in the request path of customer-facing APIs or checkout flows. That is architecturally clean (Nova fields are a first-class, documented extension point: a PHP Field subclass plus a Vue component, resolved through Nova's field and validation pipeline) but extremely narrow: the package has zero value to any application component that is not a Nova resource form. If our stack does not include a licensed Nova installation, the evaluation ends here.

Integration feasibility. Mechanically trivial: composer require, add the field to a Nova resource, optionally publish assets. The real integration work is not the package — it is the surrounding decisions: canonical storage format (E.164), country/default-region handling, whether normalization happens on save or on display, and backfilling existing free-text phone columns. Those costs exist with or without this dependency.

Technical risk. High, concentrated in provenance and maintenance rather than code quality. Zero stars, zero dependents, and a last release of November 2021 means no downstream validation of any kind — no one has publicly confirmed it works against any Nova version currently in use. Nova's frontend moved to Vue 3 in the 4.x line and Nova 5 has shipped since; a 2021-dated field component is a coin flip on rendering. The mitigating factor is that the surface is one PHP class and one Vue component under MIT — if it breaks, it is a day of work to fix, not a quarter. The non-mitigating factor is that the formatting/validation logic almost certainly delegates to a phone-number library (giggsey/libphonenumber-for-php or similar), and that dependency — not this wrapper — is where the actual correctness and staleness risk lives.

Key questions.

• Which Nova major version is this field built against, and which do we run? Has anyone verified it renders on our version?
• Is validation enforced server-side via a Nova rule, or only as client-side Vue masking? Client-only validation is a disqualifier — it silently permits malformed data through imports, seeders, and API writes.
• Does it normalize to E.164 on save, or only format for display? We need the former.
• Is this a fork of eminiarts/nova-phone-number or an independent implementation? Fork lineage affects how we reason about upstream fixes.
• Which underlying phone library and metadata version does it pull in, and can we override that constraint?
• Is there any test coverage, and does the field handle Nova's validation error display correctly (a common breakage point)?

Integration Approach

Stack fit. Laravel + Nova only. It occupies the same slot as any first-party Nova field: declared in fields() on a resource, participates in Nova's create/update and validation lifecycle. It is not a candidate for consumer-facing input, API request validation, or queue/worker code — those need direct libphonenumber usage.

Migration path. Treat this as a data-normalization project that happens to have a UI component. Sequence: decide E.164 as the canonical stored representation; add or repurpose a column accordingly; write a backfill job that parses existing free-text numbers with the underlying library and flags unparseable rows for manual review; only then expose the Nova field as the write-path formatter. Skipping the backfill produces a table with two incompatible formats and breaks search, dedupe, and SMS/voice delivery.

Compatibility. Pin the fork with an explicit Composer constraint and a nova version range. Given the release date, budget for the field component needing a Vue 3 port. Verify PHP 8.2+ compatibility. Metadata freshness should be pinned independently of the package so it can be updated without waiting on a vendor release that will not come.

Sequencing.

1. Spike in a non-production Nova instance on our exact version — confirm render, server-side rule firing, and stored value format.
2. Decide build-vs-fork explicitly. With zero upstream signal, the realistic options are (a) vendor the field class into our codebase and own it, or (b) skip the wrapper and write a ~200-line Nova field over libphonenumber directly. Option (b) is usually cheaper than adopting an unmaintained dependency and gives us the validation semantics we actually want.
3. If adopted, move to a private fork with CI, a Nova-version matrix, and a documented owner before it touches production resources.
4. Roll out per-resource, starting with the lowest-traffic admin surface.
5. Backfill and reconcile before enabling the field on high-value records.

Operational Impact

Maintenance. Effectively self-maintained from day one. A 2021 release with no dependents implies no issue triage, no Nova 5 support, and no metadata updates. The only defensible posture is to own the code: fork it, pin it, and assign an owner. The upside is that ownership cost is genuinely low — the code surface is small and the failure modes are visible in an admin UI rather than silent in production.

Support. No vendor, no SLA, no security-response channel. Any CVE in the underlying phone library or in Nova itself must be tracked by us. Confirm licensing is clean (MIT stated; verify the fork lineage does not carry a conflicting license).

Scaling. No throughput concern — admin forms are low-QPS. The one real cost is libphonenumber metadata: the full PHP metadata set is multi-megabyte and memory-heavy per process. Irrelevant for Nova, material if the same library is later reused in a high-volume API or queue worker, where the -lite variant or a trimmed metadata subset should be used instead.

Failure modes.

• Nova upgrade breaks the Vue component; field renders blank or throws silently in the admin UI.
• Client-side-only validation lets malformed numbers in through imports, seeders, and API paths, producing inconsistent stored formats.
• Stale metadata rejects valid new numbering-plan ranges or misformats recently allocated country codes.
• Inconsistent storage breaks downstream search, deduplication, and SMS/voice delivery — the highest-cost failure, and the one least attributable to this package.
• Abandonment is not a risk to model; it has already happened. Plan for it as a given.

Ramp-up. Low for a team already fluent in Nova field conventions — a mid-level Laravel developer can fork, port, and maintain this in a few days. If the team has no prior Nova customization experience, the learning cost is really Nova's field/asset pipeline, not this package, and should be scoped as such.

Recommendation. Do not take a production dependency on the upstream package: zero community signal and a three-year-old release are disqualifying for anything beyond a spike. Either vendor/ fork it with a named owner and a Nova-version test matrix, or — preferably — implement the field in-house directly against libphonenumber, which delivers the same admin UX with server-side E.164 normalization we control and a metadata update path that does not depend on an absent maintainer.