Nova Phone Field Laravel Package

Product Decisions This Supports

• Buy vs. build for Nova admin phone inputs: Adopting this package avoids custom Nova field work for country-aware phone input, formatting, and display; the 2.0.0 release strengthens the case because stored values are now canonical E.164, making the field useful beyond display.
• Data model and integration readiness: The breaking change to store E.164 means phone numbers become directly usable by downstream systems — SMS/voice providers, CRM sync, deduplication, search, and tel: links — rather than requiring ad hoc parsing of formatted strings.
• Admin UX roadmap: New copyable and helper options are small but meaningful operational improvements for support, sales ops, and back-office teams who copy phone numbers into dialers or external tools.
• Upgrade planning and migration scoping: The breaking change creates a clear PM-owned decision: schedule a data migration, define acceptance criteria for existing records, and communicate impact to teams relying on previously formatted values.
• Maintenance and standards posture: Replacing PHPCS with Laravel Pint and upgrading inputmask 5 signals active maintenance and reduced front-end defects around copy/paste and input indicators. Still, this is a small package with maintainer concentration risk; roadmap should account for fallback ownership if maintenance stalls.

When to Consider This Package

Consider it when:

• You are building on Laravel Nova and need a phone-number field with country selection, masking, validation, and formatted index/detail display.
• You want phone numbers stored in E.164 so they can be used directly by integrations, APIs, SMS providers, or identity/deduplication logic.
• Your admin users frequently copy phone numbers or need inline guidance, and the new copyable and helper options reduce support friction.
• You are comfortable adopting a small, focused package and pinning versions, with a planned migration path for existing formatted values.

Look elsewhere when:

• You are not using Laravel Nova, or you need a framework-agnostic phone library.
• You need complex phone workflows: multiple numbers per entity, extension handling, carrier lookup, line-type detection, or advanced validation policy.
• You cannot tolerate a breaking storage-format change or cannot run the provided migration query safely across existing data.
• You require enterprise-grade support, long-term commercial guarantees, or a package with a large maintainer base.
• Your product stores formatted phone values intentionally for display-only use cases and has no need for canonical normalization.

How to Pitch It (Stakeholders)

For executives: This package gives our Nova admin screens a reliable phone-number input without custom development. The new 2.0.0 release improves daily usability — users can copy numbers and see helper text — and, more importantly, standardizes stored phone numbers in E.164 format. That makes phone data usable across systems instead of trapped in display formatting. The main cost is a one-time data migration for existing records, which we should plan and validate before upgrading.

For engineering: 2.0.0 is a breaking release because values are now persisted in E.164 rather than formatted display strings. We need to audit existing data, run the documented migration query with appropriate validation and rollback planning, and verify index/detail rendering uses the updated formatting path. The package adds copyable and helper options and upgrades inputmask to v5, addressing copy/paste and indicator issues. It remains a small, focused Nova package; we should pin the version, test the upgrade in staging, and retain a fallback plan if maintenance slows.