Nova Inputmask Laravel Package

Technical Evaluation

What it is: A Laravel Nova custom field that wraps the Inputmask JavaScript library, letting Nova resource forms apply input masks (phone, postal code, currency, dates, IDs) to text fields. Architecturally it is a thin PHP field class plus a Vue component and JS/CSS assets — no schema changes, no domain logic.

Architecture fit: Nova fields are a first-class, sanctioned extension point, so the package sits entirely in the presentation layer of an admin panel. It does not touch models, migrations, queues, or APIs, which keeps coupling low and blast radius contained to back-office forms. It fits the "thin UI extension" pattern well; the only architectural concern is that Nova field packages are tightly bound to a specific Nova major (and therefore a specific Vue version), which makes them upgrade-fragile by nature.

Integration feasibility: Mechanically simple — composer require, register the field in a service provider (or rely on package discovery), then reference it in a resource's fields() method. Realistic effort is hours, not days, if the package supports your Nova version. The unknowns are the blockers: with 0 stars and 0 dependents there is no community validation, no compatibility matrix, and no evidence of Packagist publication or CI. Installation may require a VCS repository entry.

Technical risk: Bus factor of one, no downstream consumers, and no visible security or compatibility review. Nova majors break field packages routinely (Vue 2 → Vue 3 in Nova 4), so an unmaintained package is a latent upgrade blocker. Secondary risks: masked values being submitted in formatted form (e.g. (555) 123-4567) and failing server-side validation or corrupting stored data; duplicating a global Inputmask bundle; and accessibility/mobile-keyboard regressions from masked inputs. The underlying Inputmask library is MIT and widely used, so the dependency itself is not the concern — the wrapper's upkeep is.

Key questions:

• Is it installable via Packagist, or VCS-only? What Nova versions and PHP versions are declared in composer.json?
• Does it expose meaningful options (alias, greedy, placeholder, clearIncomplete, unmasked/raw value) or hardcode a single mask behavior?
• Does the field emit both the masked display value and a raw value suitable for persistence?
• Is there any test coverage, CI, or demo app? What is the last commit date and license?
• Does it behave correctly in inline-create forms, dark mode, RTL layouts, and modal contexts?

Integration Approach

Stack fit: Native to Laravel + Nova shops. Composer-native, no infrastructure change, no new runtime service. Front-end assets register through Nova's asset pipeline (Nova::script / Nova::style, or the package's build output depending on Nova version). It complements rather than competes with existing form tooling.

Migration path: Purely additive — adopting it means introducing a new field type, not modifying existing fields. Rollback is a one-line swap back to Text. Because of the low upstream trust signal, the recommended path is to fork it into an internal namespace (or a private Composer repository) before first production use, so you control pinning, patching, and Nova-upgrade fixes. Given the code volume is small, an alternative is to reimplement the same behavior in-house and treat the repo as a reference implementation; this removes upstream dependency risk entirely at modest cost.

Compatibility: Confirm the declared Nova constraint against your installed major before anything else. If it targets Nova 3 only, the Vue 2 component will not load in Nova 4/5 without a rewrite, which changes the build-vs-buy calculus decisively. Also check PHP constraint, asset build tooling (Mix vs Vite), and whether the bundled Inputmask version collides with anything already shipping an Inputmask global.

Sequencing:

1. Repo audit — license, size, last commit, tests, composer.json constraints.
2. Spike in a scratch Nova app pinned to your exact Nova and PHP versions.
3. Fork, pin to a tag/commit, patch if needed, publish internally.
4. Pilot on a single low-risk resource (e.g. contact phone on an internal-only resource).
5. Define server-side normalization and validation rules in the same PR — masks are UX only and must never be the validation layer.
6. Document standardized mask configurations, then roll out to remaining resources.

Operational Impact

Maintenance: Assume it is effectively unmaintained and that you own it from day one. The surface is small (a field class plus a Vue component), so the ongoing burden is low — but budget an annual compatibility pass for each Nova upgrade, plus an asset rebuild if Nova's front-end toolchain changes.

Support: No vendor SLA and no community to lean on; internal ownership and an internal README are mandatory. The saving grace is that the capability is cheap to rebuild, so lock-in is near zero — consistent with the low opportunity score (37/100): a convenience, not a strategic dependency.

Scaling: Negligible. The JS payload is tens of kilobytes and only loads on pages that use the field; there is no server-side cost and no query or caching implications. The only scaling-adjacent concern is duplicated asset registration or a second bundled copy of Inputmask as more resources adopt the field.

Failure modes: Silent mask loss after a Nova upgrade (field renders but stops masking); formatted values leaking into persistence; pasted already-formatted input producing doubled formatting; server validation rejecting masked strings; mobile/IME and autofill quirks; screen-reader regressions; and global script collisions. Mitigate with a browser-level smoke test on the field, a server-side canonicalizer that strips formatting before validation, and a documented "store raw, display masked" convention.

Ramp-up: Low. A Laravel developer familiar with Nova can adopt it in under an hour; modifying it requires Vue (2 or 3, depending on Nova version) and Nova field API familiarity, which narrows the pool of people who can fix it. Publish a short internal guide covering supported mask presets (E.164 phone output, fixed-decimal currency), the raw-value contract, and the fork/upgrade procedure so behavior stays consistent across teams.