Masked Field Laravel Package

Technical Evaluation

Architecture fit. Unchanged. greg0x46/masked-field remains a Nova-only custom field — a Vue component plus a Field subclass. Integration surface is still composer require + MaskedField::make('Phone') in a NovaResource. Not usable for Filament, Livewire/Inertia front ends, or API-only services. Fit remains conditional on already running Nova, still a paid closed-source product.

What v1.2.0 changes. Two of the six open questions from the prior assessment are now substantially answered:

• Nova 5 support (Q1, partially). The declared compatibility now extends to Nova 5, which implies the Vue 3 field path is being maintained. This removes the most likely near-term silent-breakage scenario and signals the package is tracking the current Nova line rather than lagging it.
• raw option (Q2, largely). The masked-vs-raw persistence question — previously the highest-severity risk in the assessment, because it can silently corrupt stored phone/tax-ID data — now has an explicit, configurable answer. That is a material de-risking, not a cosmetic one.
• Second contributor (Q1 on bus factor, marginally). A first-time external contributor landed both changes. This is a positive signal but does not meaningfully change the governance picture: one drive-by PR is not a contributor base, and commit rights/merge authority still appear centralized.

Technical risk. Reduced in severity, not in category.

• Semantics risk — down. The raw option converts a potential data-corruption failure into a documented configuration choice. Residual risk is that it must be defaulted correctly and verified per field; a permissive default that persists the masked string would reintroduce the original hazard for anyone who does not read the changelog. This is now a configuration-review item, not a blocker.
• Compatibility risk — down but re-scoped. Supporting Nova 5 is good. The open question becomes whether Nova 3/4 support was dropped or retained. If the laravel/nova constraint moved to ^5 only, that is a breaking change for existing installs and would need to be treated as a major-version event, not a minor bump. v1.2.0 is a minor semver number; confirm the constraint actually reflects that.
• Bus factor / adoption — unchanged. Still 9 stars, 0 dependents, no CI evidence, no test suite, no support commitment. The composite score of 0.255 predates this release and would move only marginally — adoption signals dominate that number and none of them moved.
• Commodity-functionality argument — unchanged and decisive. The core TPM objection was never that the package is bad; it is that input masking is a solved problem (imask, maska, Alpine directives) and a 30-line in-repo implementation carries no supply-chain, no upgrade-coupling, and no abandonment risk. The raw option and Nova 5 support make the package better, but they do not make it necessary.

Key questions (revised).

1. Does the composer constraint still permit Nova 3/4, or did v1.2.0 drop them? If dropped, this is a breaking change mislabeled as a minor and must be pinned accordingly.
2. What is the default for raw? Masked or unmasked persistence out of the box? Is the option per-field or global config?
3. Does raw change the value handed to Laravel validation/rules, or only the stored payload? Server-side rules() compatibility is still the gap between "renders nicely" and "safe to persist."
4. Is there any CI or test suite now, or does Nova 5 support rest on a manual verification by one contributor?
5. Accessibility and paste/autofill behavior — unaddressed by this release.
6. Maintainer support commitment and whether the new contributor has ongoing commit access or this was a one-off.

Integration Approach

Stack fit. Unchanged: Laravel + Nova only, now including Nova 5. Still a no-op for Filament, Livewire, or headless services. The Nova 5 support widens the addressable case for teams that have already upgraded — for teams on Nova 3/4 the relevant question is now whether they get left behind.

Migration path. Two paths instead of one:

• Package path: install pinned to v1.2.0, set raw explicitly on every field, keep the underlying column and validation rules independent of the field so removal is a one-line swap. Reversibility remains the strongest argument in the package's favor.
• In-repo path: stock Text field plus maska/Alpine. Unchanged in cost (~0.5–1 day) and now the less attractive option than before only if the team is Nova-heavy and wants format consistency across many resources.

Compatibility. This is the release-specific action item. Pin exactly, and record the matrix (Nova major × PHP × Laravel × Vue). Test on the oldest Nova version the team still runs, not just the newest — v1.2.0's headline feature is forward compatibility, and forward compatibility is often bought by dropping backward compatibility.

Sequencing.

1. Constraint audit (1 hour): read composer.json on v1.2.0 and diff against v1.1.1. Determine if Nova 3/4 are still allowed. This single check decides whether the upgrade is trivial or a migration.
2. Semantics verification (2 hours): in a throwaway branch, add the field with and without raw to one low-risk resource, save, and inspect the database column directly. Do not infer behavior from the README.
3. Decision gate — narrowed: adopt as a dependency only if the team is standardizing on Nova 5 long-term, the constraint audit is clean, and raw defaults to unmasked persistence. Otherwise the in-repo fallback remains the better endpoint.
4. Rollout: single resource → one team → all resources, with a documented rollback to a stock Text field.

Operational Impact

Maintenance. The delta is real but shallow. An external contributor shipping Nova 5 support and a requested feature is evidence the project is not dead — meaningful, given the prior assessment assumed abandonment risk. It is not evidence of a maintained dependency: no SLA, no CI, no stated support window. We still become the de facto maintainer of last resort, but the probability of needing to fork in the next 12 months is lower than previously assessed.

Support. Unchanged. GitHub issues only; Nova's commercial support does not extend to third-party fields. An admin-panel breakage from a masking field still damages internal-tooling trust disproportionately to the feature's triviality.

Scaling. Unchanged. Runtime cost is negligible. The scaling concern is format consistency across resources and teams, which an unmaintained micro-package does not enforce. The raw option slightly improves governability — a documented, explicit persistence choice beats an implicit one.

Failure modes.

• Breaking change mislabeled as minor: if v1.2.0 dropped Nova 3/4 from the constraint, a routine composer update could break every masked field on older Nova. New, and the most likely immediate failure.
• raw misconfiguration: a permissive or ambiguous default persists formatted strings, breaking validation, deduplication, and search — the original risk, now user-settable rather than intrinsic.
• Silent Nova upgrade breakage: reduced for Nova 5, still present for Nova 6+.
• Paste / autofill truncation: unaddressed.
• Accessibility regressions: unaddressed.
• Abandonment: lower probability after this release, still non-zero.

Ramp-up. Unchanged and low. One new item: the raw option adds a per-field decision that must be documented as a team convention, or different developers will configure it differently across resources and produce inconsistent data.

Recommendation — revised from "do not adopt" to "adopt conditionally, pending the constraint audit." The prior assessment recommended against adoption primarily on supply-chain and data-semantics grounds. v1.2.0 addresses the semantics risk directly and the compatibility risk partially, with a credible signal of active maintenance. The commodity-functionality argument still stands and should still make a 1-day in-repo implementation the default for a single field. But for a team already committed to Nova 5 across many resources, a pinned v1.2.0 with raw explicitly configured is now defensible where it previously was not. Gate adoption on the Nova 3/4 constraint question and on confirming raw's default; treat the composite score of 0.255 as stale but directionally valid until adoption metrics move.