Nova Tag Input Laravel Package

Product Decisions This Supports

• Build vs. buy for admin tooling. The package answers one question: do we build and maintain a custom Nova field for chip-style tag entry, or adopt a small third-party one? Its bundled scope — chip UI, placeholder/separator config, tag-count limits, Nova-native validation, and flexible storage (JSON array or delimited string) — is essentially the spec of an in-house field. Adopting it turns a small engineering project into a dependency-management decision, freeing sprint capacity for product work instead of admin plumbing.
• Shipping a narrow capability now vs. funding a taxonomy platform later. It lets you sequence lightweight tagging into an internal admin early — customers, leads, content, support tickets, assets, campaigns — while explicitly deferring the expensive work: autocomplete against existing tag libraries, hierarchical taxonomies, merge/rename workflows, per-role permissions, audit trails, and bulk operations. Write the deferred scope down on the same day as the ship decision, because stakeholders hear "tagging" and assume the whole platform.
• A forcing question about the admin stack. The field only works inside Laravel Nova, so adopting it is an implicit commitment to Nova as the internal admin layer. Surface that deliberately rather than as a side effect: are we standardizing on Nova, and do we accept small third-party fields inside it?
• Risk posture as an explicit trade-off. With 13 stars, zero dependents, a single maintainer, and a recent release (2024-12-30), the defensible product call is constrained adoption: one admin resource, feature-flagged, version-pinned, with a named owner. The cost avoided is custom field development; the cost accepted is owning a low-adoption dependency.
• Lifecycle funding and ownership. Adopting it forces an owner: version pinning in composer.lock, a source review before install, roughly one to two days a year for Nova-upgrade revalidation, and a documented fork-or-replace exit path (the package is a few hundred lines — an in-house field is a realistic fallback).
• A data-model decision with downstream reporting impact. The cleanest fit is a nullable JSON column with an array cast. If tags currently live in a comma-separated text column, this is a migration plus a reporting/validation change, not just a UI swap — a PM-level call because it touches analytics and exports, not only the admin screen.
• Demo and scoping hygiene. A chip UI invites the assumption of typeahead against our existing tag vocabulary. There is no suggestion engine here. Correcting that expectation before the demo prevents a scoping surprise that looks like a broken promise.

When to Consider This Package

Consider it when:

• The product already runs Laravel Nova for internal administration and the team wants a faster path than writing a custom field.
• The requirement is simple tag entry — free-form tags as chips — on one field of one Nova resource, not a taxonomy system.
• The feature is internal, low-blast-radius, and reversible, and a single-resource pilot before broader rollout is acceptable.
• Engineering capacity is constrained and the team would rather evaluate an existing Nova field than build and maintain one.
• The team can read the package source, pin an exact version, run a one-day spike, and test in staging on the same Nova major you run in production.
• A small, community-supported dependency confined to admin tooling is tolerable to the organization, with a fallback plan (fork, patch, or replace) agreed in advance.

Look elsewhere when:

• You are not on Nova, or you are mid-migration between Nova majors — the field is built on Nova's private front-end conventions, not a public contract, so a major upgrade can break it with no upstream fix.
• The requirement is a tag platform: autocomplete from a curated vocabulary, hierarchical categories, merge/rename/dedupe workflows, per-role permissions, audit trails, or bulk operations. That is a different, much larger build.
• Tags are a first-class query and reporting dimension — filtering, facets, or cross-record analytics. A JSON column makes LIKE queries wrong or slow; plan a generated column or a taggables join table instead.
• You need vendor guarantees — SLA, security review, or a roadmap commitment. Single maintainer, 13 stars, zero dependents: you will almost certainly be the largest consumer of this package.
• The team cannot absorb ownership of a pinned, occasionally patched dependency.
• Floating or missing nova / laravel/framework / php constraints in composer.json, or no compiled assets shipped — treat as a red flag and walk away unless you are willing to fork.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, free, open-source add-on that gives our internal admin tool standard chip-style tag entry — keywords, labels, categories — instead of us paying engineering to build and maintain that widget ourselves. It is a bounded, reversible decision: it costs nothing to license, lives only in the internal admin, and we can pilot it on a single screen behind a flag. The trade-off is honest — it is maintained by one developer with a small user base, so we pin the version, assign an owner, and keep a documented path to fork or replace it if it stops being maintained. Expect roughly a day of spike work up front and one to two days a year at Nova upgrade time.

To engineering (the ask): Read src/ before installing — verify the field's actual class name, its component(), and the declared Nova/Laravel/PHP constraints against our pinned versions. Ship it on one resource first, JSON column with an array cast, limits enforced in validation (max:10 tags, ~40 chars each, non-empty after trim), normalization at the model boundary rather than in the form. Test the contract — post a tag array to the resource endpoint and assert the persisted JSON, assert the mutator dedupes and trims, assert eleven tags fails validation. Keep the previous representation behind a one-line switch for a release. Pin the exact version in composer.lock and name an owner.

What we are explicitly not buying: autocomplete, a tag library, taxonomy hierarchy, merge/rename workflows, per-role tag permissions, or a query/reporting layer. If any of those become requirements, that is a new and much larger project — not a configuration change to this one.