Nova Tags Input Laravel Package

Product Decisions This Supports

• Tag/label taxonomy editing inside Laravel Nova admin panels. This package is a single-purpose Nova field that swaps a plain text/JSON input for a vue-tags-input chip UI. Its product value is entirely contained in internal admin tooling: managing keywords, content labels, segment tags, or category arrays on a model.
• A build-vs-buy data point — but a weak one. With 2 stars, 0 dependents, and an archived repo, the "buy" side of the ledger has effectively no supporting evidence. The honest read is not "should we adopt this?" but "should we write ~100–200 lines of our own Nova field?" — this repo is useful mainly as a reference implementation of that field.
• Roadmap scoping for admin/back-office work. If tagging UX is on the roadmap only for internal operators (content editors, support staff), a custom Nova field is a low-risk, low-cost increment. It is not a decision input for anything customer-facing, anything with an SLA, or anything that needs to survive a Nova major-version upgrade.
• Ecosystem signal. Zero dependents and an archived state tell you the "Nova tags field" niche is thin. Budget for owning the code regardless of which route you take; do not assume a maintained off-the-shelf option exists.

When to Consider This Package

Consider it only as a reference or fork, not as a Composer dependency:

• You are on a Nova 2/3-era application that already matches its peer requirements, you need tag chips on an internal-only screen, and you have explicitly accepted ownership of the code.
• You want a working example of how to wrap vue-tags-input into a Nova Field class rather than starting from a blank file.

Look elsewhere — or build — when:

• You are on a current Nova/Laravel version. An archived Nova field will not track Nova's field API changes, and Nova majors break third-party fields regularly.
• The tags need to be searchable, deduplicated, or relational. Use Nova's built-in BelongsToMany field with a searchable select backed by a real tags table, or spatie/laravel-tags for the domain model plus a thin custom field for the UI.
• You need tests, a security review, a maintenance owner, or vulnerability patching. Archived means none of these exist, and 0 dependents means nobody else has validated the code path.
• The surface is customer-facing or on any reliability commitment.

How to Pitch It (Stakeholders)

Executive summary: This is a small, unsupported UI convenience for internal admin screens. It has no adoption (2 stars, 0 dependents) and is archived upstream, so it carries maintenance risk with no mitigating community. Recommendation: do not add it as a dependency. If tagging UX is needed, scope a one-to-two-day in-house Nova field — that cost is lower than the risk of inheriting dead code.

For engineering: "Archived Nova 3-era field wrapping vue-tags-input. No version guarantees against current Nova. Two options: (a) spend ~1–2 dev days writing a custom Field with tests, or (b) use the built-in BelongsToMany + searchable select if tags are relational. Option (b) is the default; option (a) only if we specifically want free-text chips with no backing table."

The ask: decision on where tags live — a related tags table (relational, searchable, reusable) versus a JSON column (simple, free-text). That modeling choice matters far more to the product than which input widget renders it, and it should be made before any implementation is scheduled.