Input Mask Laravel Package

Technical Evaluation

Architecture fit — conditional, and narrower than the package claims. The description frames this as a general-purpose Laravel masking library with Blade directives and helpers. The repository is a Laravel Nova custom field: one PHP Field subclass that passes mask metadata plus a Vue component that renders the masked input inside Nova's admin UI. It contributes nothing to Blade, Livewire, Inertia, API resources, or validation. Architecturally it is a presentation-layer widget with no domain-layer surface, no service provider capability, and no extension point beyond the frontend component. Fit is therefore binary: if the target surface is a Nova resource form, it fits; anything else, it does not.

Integration feasibility — small but time-boxed to a specific Nova era. The whole package is two files plus a bundled JS mask library, so the read-and-understand cost is hours, not days. Feasibility hinges on one fact: last release 2019-05-16 places it in the Nova 1.x/2.x, Vue 2 generation. On a legacy Nova install, integration is a composer require, a field registration, and an asset publish. On Nova 4/5 the frontend is Vue 3 and the component is a rewrite, at which point "integrate" collapses into "rebuild using this as a reference." Composer constraints and asset-pipeline assumptions from 2019 are the second-order friction.

Technical risk — four independent risks, none of which the package mitigates.

• License. GPL-3.0 is a genuine outlier in an MIT-dominated ecosystem. Internal unmodified use is usually defensible; distributed, on-prem appliance, or client-delivered code triggers copyleft obligations. This is a release gate requiring legal sign-off, not a footnote.
• Abandonment. 11 stars, 0 dependents, no release in six years, no community to absorb future Nova upgrades. There is no security response path, and the unexamined risk sits one layer down in the bundled JS mask library (version, CVE state, input handling).
• Data correctness. Masks format; they never validate. The field almost certainly submits the masked string verbatim. Any downstream rule, LIKE, join, or export assuming digits will be silently wrong unless normalization is added independently of the package.
• Documentation unreliability. The copy and the source disagree about what the package even is. Planning against the README is a documented failure mode; source is the only truth.

Key questions to resolve before any sprint commitment.

1. Which Nova major are we on? This single answer decides adopt vs. build.
2. What is our distribution model, and has legal cleared GPL-3.0 for it?
3. What exact formats/tokens do we need, and do they survive a paste-and-save spike on our Nova version?
4. Where does normalization live — FormRequest, model mutator, or both — and who owns the tests?
5. What is the canonical stored form, and does it match existing column contents?
6. Do we have accessibility commitments that a keystroke-swallowing mask violates?

Integration Approach

Stack fit. Nova-only. The PHP class is a metadata carrier; all behavior lives in resources/js/. That means the integration surface is (a) field registration in fields(), (b) asset publishing, and (c) the frontend component. There is nothing to wire into controllers, jobs, commands, or API layers, and no runtime coupling to application code beyond the admin bundle.

Migration path — two viable shapes, pick deliberately.

• Adopt (legacy Nova only). Subclass the vendor field immediately so the vendor namespace appears exactly once: App\Nova\Fields\MaskedText with fluent helpers (->phone(), ->document()). Every call site references our class, so swapping or porting later touches one file. Pair it with prepareForValidation() normalization in the FormRequest and displayUsing() formatters on index/detail, so the stored value is canonical digits and the mask is re-applied only at render time.
• Build (default for Nova 4/5, and my recommendation generally). Port the two source files into nova-components/, replace the bundled mask plugin with a maintained one (IMask or cleave.js), target Vue 3, and own the rebuild. Estimated 1–2 engineering days. This yields Nova-version compatibility, an MIT-clean license, and a mask library we selected.

The rule that survives either path: masks are presentation only; server-side validation plus a normalizer is mandatory and belongs to us, not the package.

Compatibility. Verify in this order: Nova major → composer.json constraints (laravel/nova, PHP) → package.json bundled mask library name/version/license → asset build (nova:publish, npm run dev) → browser behavior. Then run the spike matrix against the exact formats we intend: type, paste a pre-formatted value, paste an unformatted value, clear the field, submit empty, submit via autofill. Mask libraries diverge sharply on each of these and the README tells us nothing.

Sequencing.

1. Legal/GPL determination and Nova version check — both are gates, run them in parallel and first.
2. Time-boxed spike (≤1 day) on one resource, saving and inspecting the DB row.
3. Decide adopt vs. build on spike evidence, not on the description.
4. If adopting: private fork, version pin, named owner, dependency inventory entry.
5. Land the wrapper class and the FormRequest normalizer together — never the field alone.
6. Add display formatters so the mask's value survives outside the edit form.
7. Roll out resource by resource, not as a sweep.

Operational Impact

Maintenance. There is no upstream maintenance to inherit — only a liability to contain. Adopting means committing to a private fork, an exact version pin, a named owner in the dependency inventory, and remediation at every Nova major upgrade (every one of which will require touching the Vue component). The realistic steady-state cost is not the initial integration but the recurring port. For a 1–2 day rebuild, the break-even against "own a 2019 fork forever" is immediate.

Support. No maintainer, no security response path, no issue community, no upgrade commitments. All triage is internal. Because the documentation is unreliable, the source remains the de facto runbook — which is fine at two files, but it means the knowledge sits with whoever read them. Encode it in the wrapper class and an internal README so it does not become tribal.

Scaling. Technically this is a non-issue: a single admin field with no server-side request cost beyond the existing Nova bundle, no background work, no external calls. The scaling concern is organizational — every resource that registers the raw vendor field multiplies the later port and the normalization surface. The wrapper class is what keeps that linear instead of combinatorial, and the normalization layer is what keeps data quality independent of how many fields are masked.

Failure modes to instrument for.

• Silent de-formatting. Component stops rendering the mask after a Nova upgrade or asset change. Diagnose by dumping $field->meta() in fields() to confirm metadata reaches the frontend, then check the Nova console for a failed Nova.booting registration. Usually Vue version mismatch or unbundled assets, not mask config.
• Masked strings persisted. Validation silently fails, search/joins/exports silently break. Detect with a post-save DB inspection in the spike and a normalizer test in CI.
• Paste and autofill mangling. Pre-formatted input into a bare-digit assumption produces corrupted values. Normalize defensively server-side regardless of what the widget claims.
• Accessibility regression. Keystrokes rejected mid-mask with no feedback confuse screen-reader and keyboard-only users. Add help text describing expected format if we have accessibility commitments.

Ramp-up. A developer already fluent in Nova fields is productive in hours on the adopt path; days if porting the Vue component. Legal review is calendar time, not effort, and it should be started before the spike rather than after — it is the most likely source of schedule slippage on a package this small. Onboarding cost concentrates in one place: whoever owns the fork owns an undocumented, unmaintained 2019 frontend component, so assign that ownership explicitly at decision time rather than inheriting it by default.