Input Mask Laravel Package

Product Decisions This Supports

• Admin data-entry quality (the only real use case). If internal operators key in Brazilian formats — CPF/CNPJ, phone, postal code, dates, currency — a masked input reduces typos and rework on back-office screens. The value is measured in saved keystrokes and fewer correction cycles, not in roadmap leverage or differentiation. Treat it as a line item inside an "admin experience" backlog, never a standalone initiative.
• Build-vs-buy calibration — the decision anchor. The scope is genuinely thin: one Laravel Nova Field class plus a JavaScript mask call. A PM can reasonably cap the in-house alternative at 1–2 engineering days using a maintained library (IMask or cleave.js). If the "buy" path instead requires legal review, a private fork, a named owner, and permanent upgrade remediation, building wins on total cost of ownership — not on feature merit.
• Explicit non-goals to state in writing. It does not validate input, does not normalize what gets persisted, does not improve public-facing forms, and does not guarantee clean records. If a stakeholder frames this as "solving our input quality problem," correct that in the same conversation — otherwise the team ships formatting and still owns the bad data.
• The durable product requirement, independent of the package. Masks are presentation only. Server-side validation plus a normalizer (strip non-digits, parse currency, canonicalize dates) is mandatory and needs tests. That decision survives; the masking widget is a swappable implementation detail. This is also the fork in the road that determines whether you store raw digits and format on display (best for search, joins, and exports) or store masked values — pick one and hold it across all resources.
• Localization signal. Built-in presets are Brazilian formats. If Brazil/LatAm is a target market, that's a mild argument for a small in-house locale-aware input kit rather than adopting a dormant single-field package. If it isn't a target market, the presets are simply irrelevant.
• Roadmap weighting: near zero. 11 stars, 0 dependents, last release May 2019. It creates no strategic dependency and no platform capability. Any adoption is tactical and local to a handful of Nova resources.
• Two gates the PM must surface rather than delegate. First, GPL-3.0 is a genuine outlier in a Laravel/Nova ecosystem that is overwhelmingly MIT; copyleft obligations in a distributed, on-prem, or client-delivered product require legal sign-off — that's a release gate, not a footnote. Second, Nova version compatibility — a 2019-era Vue 2 field almost certainly breaks on Nova 4/5's Vue 3 frontend. Don't schedule sprint capacity without a verified spike.

When to Consider This Package

Consider it only if all of these hold:

• You are on a legacy Nova 1.x/2.x install and need a masked field this sprint.
• The surface is internal admin tooling, where breakage is an inconvenience rather than a customer-facing incident.
• You have verified render-and-save behavior on your exact Nova version in a timeboxed spike (≤1 day) against the tokens and formats you actually intend to use — testing paste, browser autofill, clear, and empty submit, not just "does it render."
• Legal has cleared or waived GPL-3.0 for your distribution model.
• You will fork it into a private VCS, assign a named owner, pin the version, and add it to the dependency inventory — i.e., you are buying a code sample, not a dependency.

Look elsewhere — or build — when:

• You are on Nova 4/5. This is the single biggest disqualifier; expect to rewrite the front end regardless of how small the package looks.
• The product is commercial or distributed and copyleft is undesirable. Build an MIT-clean field instead.
• You need server-side validation, normalization, i18n, multiple mask variants per field, or accessibility guarantees — masks are display-only and cannot carry any of these on their own.
• You need a maintained upstream with a security response path and Nova-version compatibility commitments. None exist here, and there is no community to absorb future upgrades; the bundled JS mask library's version and CVE state are likewise unexamined.
• The requirement is public-facing forms (Blade/Livewire/Inertia). Evaluate a maintained form/mask library against your design system; this package's Brazilian presets and 2019 toolchain won't meet modern expectations. Note the documentation describes a general-purpose Blade-friendly library while the repository is a Nova-only field — treat the copy as unreliable and the source as the only truth.
• You want to customize behavior. All logic lives in the Vue component under resources/js/; the PHP class only passes metadata. Customizing means owning the front-end rebuild, which is rarely the cheap option it appears to be.

How to Pitch It (Stakeholders)

Bottom line: use it as a reference implementation, not a production dependency.

• Executives: This is a free UI nicety for admin screens that saves operator keystrokes on Brazilian document, phone, and date formats. It has been unmaintained since May 2019, has negligible adoption (11 stars, 0 dependents), and carries a GPL-3.0 license requiring legal review before it ships in anything commercial or client-delivered. Rebuilding the equivalent in-house costs roughly one to two engineering days with a maintained masking library, so there is no business case for taking on the dependency risk. Recommendation: do not add it to the production dependency tree; approve a one-to-two-day in-house Nova field if admin data-entry quality is prioritized.

• Engineering: It's a thin wrapper — a Nova text field plus a JS mask call, with all behavior in the Vue component and all PHP surface in a single Field class. Reimplementing gives us Nova-version compatibility, an MIT-clean license, and control over which mask library we depend on and who patches it. Read the two source files, copy the Vue component, swap in IMask or cleave.js, bump to Vue 3 for Nova 4+, and ship it as a local component in nova-components/. Budget the spike explicitly: confirm Nova major and PHP/laravel/nova constraints first — that single answer decides adopt versus build — then verify whether the field persists (11) 99999-8888 verbatim or strips mask characters, and normalize in the FormRequest layer regardless so validation rules can speak in canonical digits.

• Ops / internal users: They get formatted, easier-to-scan inputs on admin screens, which reduces typos and correction cycles. Set the expectation plainly: the mask guides typing, it does not enforce correctness, and pasting a pre-formatted value may behave unexpectedly. Expect to ship a helper text describing the expected format — accessibility for masked inputs is unowned by this package, and keystroke-swallowing behavior is confusing for keyboard-only and screen-reader users.