Nova Tags Field Laravel Package

Product Decisions This Supports

• Build vs. buy for back-office taxonomy. Tagging is commodity UX — no customer picks your product for its tag input. This package turns "should we spend a sprint on an admin tag field?" into a composer require plus a fields() entry. The decision it actually forces is narrower and more useful: is a 10-star, single-maintainer Nova field acceptable inside an internal-only workflow our ops team touches daily? Answer that, and you've set a precedent for how you tier every small dependency.
• Roadmap sequencing. Tagging (record labels, CMS-style categorization, CRM segments, campaign grouping) is low-differentiation work that shouldn't consume a sprint. Shipping it via a dependency frees capacity for work that moves a metric. Frame the win as "capability delivered at near-zero engineering cost," not "we adopted a package."
• Explicit deferral as a PM artifact. Adopt "tags exist" now; write down that tag hierarchies, per-tag permissions, external taxonomy sync, and tag-based reporting are later, separately justified items. The written deferral is the deliverable — it prevents scope creep from turning a two-day install into a quarter of schema work.
• The expensive, hard-to-reverse decision: the data model. The description says it uses cartalyst/tags (polymorphic pivot, shared taxonomy, cross-model queryability, migrations). The integration guidance describes a flat JSON array with an array cast (per-record, no shared vocabulary, whereJsonContains filtering that won't scale). Those are materially different products with different reporting ceilings. Resolve this before committing — the package is cheap to swap; the schema is not.
• Vendor-risk policy. 10 stars, 0 dependents, last release 2023-03-31, and the only recent maintenance signal is a cosmetic dark-mode CSS patch (PR #13). That's enough to conclude "not abandoned," not enough to conclude "safely maintained." The correct output is a risk-accepted, internal-only adoption with a documented exit and a named owner — not a strategic bet.
• Where it should not go: customer-facing tagging, any workflow where a broken tag input blocks orders/fulfillment/support, or any surface where tags become filterable, aggregated, or reported on. Those warrant first-party ownership.

When to Consider This Package

Consider it when all of these hold:

• You already run Laravel Nova for back-office. This is a Nova form field, not a tagging library — outside a licensed, actively used Nova app it has zero value. Confirm that gate before spending engineering time.
• The need is simple tagging on a resource — a searchable select-or-create input, no separate CRUD screen.
• The workflow is internal and non-critical: a degraded tag UI is an annoyance, not an incident, and a comma-separated text field is an acceptable fallback for a few hours.
• You can pin the version and absorb Nova upgrade testing as a standing cost. Nova fields are tightly coupled to Nova release lines, and this one's cadence stopped in early 2023 — Nova 5 support is unverified.
• Theme consistency matters — 4.0.1 adds dark-mode support, relevant if your admin UI ships a dark theme.

Look elsewhere — or build — when:

• You're not on Nova, or you need tagging in customer-facing UI, APIs, or Blade/Vue surfaces.
• You need richer semantics: hierarchies, per-tenant vocabularies, tag-level permissions, taxonomy sync, or tag-driven reporting.
• You need first-party support, an SLA, or a security-review trail. Ten stars and zero dependents won't survive procurement or a platform dependency policy.
• Tags become a product surface. If they'll be filtered or reported on, own the schema and the writes — API and CLI writers bypass the field's validation entirely.
• Your Nova major is newer than the tested line and you can't cheaply verify compatibility.
• You need custom chip rendering, async lookup, or a real Tag relation. The stated extension path is "publish and fork the Vue components" — that's most of the build, so skip the dependency.

Guardrails before adoption: pin the exact version and record the rationale; add the array/AsArray cast (the most common integration bug); mirror tag constraints in model-level validation and normalization so admin and API writes converge; name an internal owner; pre-agree the fork trigger (a Nova major bump, or a month of broken UI) with the exit cost stated up front.

How to Pitch It (Stakeholders)

To executives: We can deliver tagging in our internal admin panel in days rather than weeks with a small MIT-licensed Nova form field. It's a UI-only dependency — it doesn't touch customer-facing code, revenue paths, or any operational workflow — and it's trivial to remove. The trade-off is counterparty risk: a community package from a small maintainer, last updated in early 2023, with no downstream ecosystem to catch its mistakes. That's acceptable for back-office convenience and unacceptable for anything operational. Recommendation: adopt narrowly inside the admin tool, pin the version, nominate an owner, and treat "build it ourselves" as the fallback the moment tagging becomes something we report on or automate.

To engineering: A drop-in Nova field giving a searchable select-or-create tag input. Two things to plan for. First, there's a storage-model contradiction to settle in a one-to-two-day spike before we design anything: the description implies a polymorphic pivot via cartalyst/tags, while the integration guidance describes a flat JSON column with an array cast. Read the shipped 4.0.1 source, not the marketing copy — schema and reporting capability hinge on it. Second, the field is a thin UI layer; the model column stays the source of truth, so normalization, dedupe, and validation belong in the model or API/CLI writes will drift from admin-entered data. Budget roughly half a day for composer require, one fields() entry, nova:assets, and a light/dark render check — plus a standing smoke test on every Nova major, since field packages break quietly. Pin 4.0.1, record the pin in the decision log, and name the owner of the published Vue components now rather than during an incident.