Nova Tags Input Laravel Package

Technical Evaluation

Architecture fit. Nova custom fields are a well-bounded extension point: a PHP Field subclass declaring component(), attribute hydration/serialization, and a Vue SFC registered via a service provider's Nova::script / Nova::style calls. This package targets exactly that seam — no core patching, no service-container hijacking, no route or middleware interception. The blast radius is one field type, which is the single strongest argument in its favor. The problem is that the seam it targets is version-specific: vue-tags-input is a Vue 2 library, which pins it to Nova 1–3. Nova 4 moved to Vue 3 and a Vite-based asset pipeline, and Nova 5 continues that lineage. "Which Nova major are we on?" is therefore not a nice-to-have question — it is a go/no-go gate that determines whether this is an integration or a rewrite.

Integration feasibility. Vendorable in an afternoon; ownable only with deliberate investment. The package is small enough to read end-to-end in a sitting, which is the right move before any commitment. The countervailing signals are unambiguous: 2 stars, 0 dependents, archived, composite score 0.005. Zero dependents means no third party has ever run this in production and reported back — there is no issue trail, no compatibility matrix crowdsourced from real deployments, no one else's scars. Archival means the maintainer has explicitly withdrawn support.

Technical risk. Ranked: (1) archived upstream with no patch path; (2) Vue 2 end-of-life (Dec 2023) — no security backports anywhere in the render chain; (3) unvalidated serialization semantics — whether tags persist as JSON array, CSV, or delimited string determines whether existing filters, index columns, and API consumers keep working; (4) asset-registration conflicts with Nova's compiled bundles; (5) no test suite, so there is no behavioral baseline to diff against during a Nova upgrade; (6) supply-chain opacity for transitive dependencies frozen at whatever lockfile state the repo was abandoned in. Opportunity score of 14.11 reflects a package that solves a real gap (Nova ships no native tag input) but does so in an unmaintained artifact.

Key questions.

• Which Nova major, and therefore which Vue major, are we pinned to?
• What is the current persistence format for this field, and does it round-trip cleanly through Nova filters, index views, and API resources?
• Does the field enforce array validation rules server-side, or is validation purely client-side?
• Who owns this code after adoption, and what is the upgrade SLA when Nova ships a major?
• Is there existing tag data anywhere in the estate that must remain readable?

Integration Approach

Stack fit. Laravel + Nova + Vue, with the Vue major being the deciding variable. If the estate is on Nova ≤3, the package is plausibly usable. On Nova 4/5, it is a reference implementation, not a dependency.

Migration path. Three routes, in ascending order of cost and descending order of regret:

1. Depend on it as-is — rejected. Depending on an archived package with zero dependents is a known-bad trade; the dependency will outlive its support.
2. Vendor the source — recommended for Nova ≤3 shops. Copy the PHP field and Vue component into an internal package under our namespace, verify licensing permits it, add characterization tests, and own it outright. The package is small; this is hours, not weeks.
3. Reimplement on a maintained primitive — recommended for Nova 4/5. Build a first-party Nova field wrapping a currently-maintained Vue 3 tag component, using this repo's serialization and validation choices as a design reference.

Either way, treat the repository as a specification, not an artifact to install.

Compatibility. Pin the Nova major, PHP version, and Node/build toolchain explicitly. Verify the field's asset build integrates with the project's nova.mix.js pipeline rather than assuming the repo's prebuilt assets are current. Confirm validation rules fire on array input, not just on the string representation.

Sequencing.

1. Version gate — confirm Nova and Vue majors; kill the effort here if mismatched.
2. Full source read and license check (small enough to be mandatory).
3. Vendor into an internal package namespace with characterization tests covering create, edit, index, filter, and API serialization.
4. Round-trip validation on a scratch resource, including an edit-after-create cycle to catch serialization drift.
5. Roll out to a single low-traffic resource before any broad adoption.

Operational Impact

Maintenance. Effectively 100% ours on day one. Archival means no upstream patches, ever. Budget explicitly for Nova major upgrades, Vue major migrations, and security advisory triage across transitive dependencies — none of which anyone else will do for us.

Support. No maintainer, no issue activity, no community. Internal documentation and a named owner are prerequisites, not nice-to-haves. Minimum viable runbook: what breaks when Nova upgrades, and how we detect it before users do.

Scaling. Runtime cost is negligible — this is a form input. The real scaling risk is organizational: a field type spreads across resources, becomes the de facto standard for tag entry, and then quietly becomes the blocker on a Nova upgrade. That is the failure mode to design against, and it argues for wrapping the field behind a thin internal abstraction so the underlying implementation stays swappable.

Failure modes.

• Nova upgrade silently breaks asset registration or component resolution.
• Serialization drift corrupts tag data on edit — worst case, because it is silent.
• Vue 2 EOL exposure with no CVE response path.
• Orphaned transitive dependency with no one to patch it.
• Bus factor of one — already realized by archival.

Ramp-up. Hours for a Laravel/Nova-fluent engineer to read and vendor the source. The expensive part is not ramp-up to use it; it is ramp-up to trust it, which requires writing characterization tests before first deployment. Fund that explicitly or skip the package.

Bottom line. The gap is real — Nova has no native tag input — but this artifact is not a viable long-term dependency at 2 stars, 0 dependents, and archived status. Adopt the design, not the package: vendor or reimplement, own the code, and gate the decision on Nova major compatibility before spending anything further.