Masked Field Laravel Package

Product Decisions This Supports

• Feature-level decisions: Standardizing structured data capture (phone numbers, SSNs, EINs, credit cards, dates, license plates) inside Laravel Nova admin panels so operators enter records in a consistent format rather than ad-hoc free text. As of v1.2.0 this now applies to Nova 5 admin panels, so the same decision holds for teams on the current Nova major.
• Data quality and compliance: Masked inputs reduce keystroke errors and enforce shape at point-of-entry, which matters for any workflow touching PII, financial records, or regulatory forms (KYC onboarding, support tickets, billing changes). v1.2.0's new raw option adds an explicit product choice here: keep the masked string for display/audit fidelity, or submit the raw value and normalize on the server. Recommended default is raw + server-side validation/cast, so the database stays canonical and formatting stays a UI concern.
• Build vs. buy (small vendor): A masked-field component is 1–3 days of internal work to build and test well. This package is a thin wrapper around an established JS mask library, so the real decision is "adopt a low-adoption dependency vs. vendor a ~100-line field" — not a major investment either way. The v1.2.0 raw option removes one of the small reasons to vendor (previously you might have needed custom code just to control the submitted value).
• Roadmap signaling: Useful as a low-cost pilot to test whether masked input measurably reduces data correction work in ops. Nova 5 support extends the pilot's shelf life across an upgrade cycle — worth noting if your roadmap includes a Nova 4 → 5 migration, since this avoids re-solving the field during that move.
• Scope constraint: It only solves the display/entry side. Validation, normalization, and storage still require your own Nova rules and model casts — this is a UX layer, not a data-integrity guarantee. The raw option changes what value you receive, not whether it is valid.

When to Consider This Package

Consider it when:

• Your team already runs Laravel Nova (this is a Nova field; it has no standalone use). Note the v1.2.0 release explicitly adds Nova 5 support — confirm against your exact Nova minor version before rollout, and verify Nova 4 support if you are mid-migration.
• You need masks on a handful of Nova form fields and want them consistent across resources without writing custom Vue components.
• You want control over whether the stored/submitted value is the masked string or the raw value — v1.2.0 makes this configurable rather than requiring a fork.
• You can accept a small, single-maintainer dependency (low stars/dependents as of last review, historically one maintainer). The v1.2.0 release does show a new external contributor landing changes, which marginally improves bus factor but does not turn this into a supported product.
• Time-to-value matters more than long-term support contracts; you can swap it for an in-house field if needed.

Look elsewhere when:

• You are not on Nova — use a framework-agnostic JS mask library (e.g., IMask, Cleave) directly, or a Filament/other-admin equivalent.
• You are on an older Nova major and cannot confirm compatibility; v1.2.0's headline change is Nova 5 support, so pin and test on a branch first.
• You need validation guarantees — this handles input formatting, not server-side validation; pair with Nova rules and casts regardless. The raw option makes this pairing more important, not less, since unmasked values can be shorter or malformed.
• You require accessibility conformance, i18n masks, or documented test coverage — verify against your standards or build in-house.
• Security/compliance posture is strict (PII-heavy, audit requirements): a low-adoption dependency in an admin panel warrants a review or clean-room reimplementation.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, cheap UI component for our Laravel admin panel that forces operators to enter phone numbers, IDs, and financial details in a consistent format. It reduces data-entry errors and cleanup work in the back office. The new version supports the current Nova release and lets us choose between storing the formatted value or the clean underlying value — the latter is what we want. Cost is near zero; the main caveat remains that it's a small community package, so we treat it as low-risk tooling and keep it pinned and reviewable.

For engineering: A Nova field wrapping a JS input mask. v1.2.0 adds Nova 5 support and a raw option, plus a first-time external contributor. Recommendation: pin the version, add it to our dependency review, and use raw mode behind validation rules and casts so the database remains the source of truth. Upgrade path is low-risk but verify our Nova version and run a smoke test on one resource before wider rollout; confirm whether Nova 4 remains supported if we still have panels there. If we decide the maintenance risk isn't worth it, the fallback is a ~1-day internal Nova field using a maintained mask library — same UX, full control.