Nova Tags Field Laravel Package

Technical Evaluation

Architecture fit. This is a back-office UI extension, not a platform component. It plugs into a Nova resource's fields() method and renders a searchable select-or-create tag input; it never touches routing, domain services, queues, APIs, or customer-facing surfaces. That makes it the lowest-risk integration class we can take on — a Composer dependency scoped entirely to the admin layer, with blast radius capped at a handful of admin screens and a trivial removal path. The one hard gate: it is Nova-only, so confirm Nova is licensed and in active use before any engineering time is spent. Outside that context the package has zero value. Position it in the roadmap as an "internal tooling UX accelerator," not a dependency the product builds on.

Integration feasibility. Mechanically trivial: composer require, one field line per resource, php artisan nova:assets. The real feasibility question is a documentation contradiction that must be resolved before we commit budget. The description claims the package "uses cartalyst/tags," while the Laravel-level integration guidance describes persisting a flat JSON array with an array/AsArray cast. Those are materially different data models with different downstream ceilings:

• cartalyst/tags implies a polymorphic taggable pivot, a shared tag namespace, cross-model queryability, and migrations to own.
• A JSON column implies a per-record array, no shared taxonomy, and filtering via whereJsonContains that will not scale to large datasets.

That distinction drives schema design, reporting capability, data migration effort, and whether tags are reusable across records. It must be answered by reading the shipped 4.0.1 source and README — not the marketing copy. This is the single highest-value diligence item a TPM can force here: a half-day spike that prevents a quarter of schema regret.

Technical risk. Tier this as low adopter risk, high sustainability risk, and manage the two separately.

• Adopter risk is low: MIT licensed, tiny surface, isolated to admin UI, trivially removable. Total failure costs a sprint, not a quarter, and the degraded mode (a plain comma-separated text field) is a few hours of work.
• Sustainability risk is high: 10 stars, 0 dependents, last release 2023-03-31, score 2.39, opportunity 28.23. Zero dependents means zero evidence of production use — no proxy for battle-testing. Nova field packages are tightly coupled to Nova release lines, and a cadence that stopped in early 2023 leaves Nova 5 compatibility unverified and probably unmaintained. The only recent upkeep signal, 4.0.1 (PR #13, "Support Dark Team"), is a cosmetic CSS patch with a visual-regression profile and no API or schema change — enough to say "not abandoned," not enough to say "safely maintained."
• Organizational risk: effectively a single small-agency maintainer with no SLA and no evident issue-response commitment. At this adoption level, "buy" is a euphemism for "fork with a head start."

Key questions.

1. Which Laravel/PHP and Nova major versions are supported — is Nova 5 in scope, or is this a Nova 4-only artifact?
2. Does the shipped 4.0.1 code genuinely integrate cartalyst/tags (pivot + migrations), or persist a JSON array on the model? README and source may disagree.
3. Is there test coverage, CI, and a documented support expectation, or is maintenance purely best-effort?
4. What is the security posture for a control rendering user-supplied tag text — escaping, XSS in chips, dropdown rendering?
5. What is the exit cost if upstream goes dark — can we vendor/fork the field in a day, and who owns that?
6. Are there breaking changes between 4.0.0 and 4.0.1, and what is the upgrade checklist for existing installs?

Integration Approach

Stack fit. Suitable only where the stack is Laravel + Nova and the need is an admin-facing tag input for content taxonomy, record labelling, or CRM-style segmentation. Explicitly not a fit for non-Nova Laravel, Blade/Vue frontends, or any customer-facing surface. Confirming Nova is licensed and in use is the gate that kills a surprising share of "should we adopt this?" conversations — clear it first.

Migration path. Split by cohort, because the work is asymmetric.

• Existing 4.0.0 users: lockfile bump to 4.0.1, run nova:assets, hard-refresh, and visually verify the input in both light and dark themes. No data migration and no config change implied by the patch.
• New adopters: do not treat this as a straight install. Run a timeboxed spike (1–2 days) in a throwaway branch that (a) resolves the cartalyst/tags versus JSON storage question against actual source, (b) proves create/read/update/search/filter end-to-end on one resource, and (c) confirms the model cast. Only then commit to a storage contract — the package is cheap to try, the schema is expensive to reverse.

Compatibility. Treat Nova major-version alignment as a standing gate, not a one-time check. Verify the supported Nova version against current and next-planned majors; if a Nova upgrade sits inside the dependency's lifetime, budget for replacing or forking at that moment. Pin the exact version (4.0.1) in the lockfile and record the pin plus its rationale in the decision log so the next engineer understands why it is frozen.

Sequencing.

1. Decision gate: confirm Nova version and resolve the storage-model ambiguity → go/no-go.
2. Spike: install in a throwaway branch, wire one resource, exercise CRUD, filter, and both themes.
3. Contract decision: JSON column with model cast or cartalyst/tags relational model — document it, and put normalization (trim/dedupe/lowercase) in a model mutator so admin writes and API/CLI writes converge.
4. Build: add field definitions, mirror Nova rules() with model-level validation (API and CLI writers bypass Nova validation entirely), and apply onlyOnDetail/hideFromIndex where rendering cost matters.
5. Test: Pest/PHPUnit assertions on the persisted attribute array, a field-definition snapshot to catch config drift on upgrade, and explicit dark-mode acceptance criteria.
6. Ship: pinned version, rolled out to a limited set of resources first, monitored.
7. Contingency: pre-agree the fork trigger (e.g., a Nova major bump, or more than a month of broken UI) and name the owner of the published Vue components.

Weigh build vs. buy honestly: a Nova tag field is a few hundred lines. If the need outgrows simple labelling — custom chip rendering, async lookup, a real Tag relation — the package's stated extension path ("publish and fork the Vue components") is most of the build anyway, so skip the dependency and build.

Operational Impact

Maintenance. Low, but not zero, and it must be owned. Standing costs: Nova upgrade smoke tests on every major, a pinned lockfile, and periodic checks that the upstream repo hasn't gone dark. Assign a named internal owner — this is the single most important operational control for a 10-star, single-maintainer dependency. The version pin plus a documented rationale in the decision log prevents silent drift.

Support. There is none — no SLA, no vendor, no procurement-safe security trail. That is acceptable for internal-only admin convenience and unacceptable for anything operational. The support model is: we support it ourselves, and the fallback is the published Vue components forked into our codebase. State that in the adoption record so the escalation path is explicit before it is needed.

Scaling. Fine for the intended use — modest admin screens, a handful of resources. Two scaling caveats: a JSON-column model won't support tag-based reporting or aggregation at volume (JSON-path filtering degrades), and rendering many tag chips on index views costs front-end cycles, so use hideFromIndex/onlyOnDetail where it matters. If tags become a filterable, aggregated, or reported-on dimension, that's the signal to migrate to a first-party relational schema — plan that as a separate, justified roadmap item rather than stretching this package.

Failure modes. Enumerate them up front so they are annoyances, not incidents:

• Nova upgrade breaks the field quietly — most likely failure mode; field packages break silently on Nova majors. Mitigation: smoke test on every Nova bump, fork trigger pre-agreed.
• Storage-model mismatch — the JSON-vs-pivot ambiguity surfacing late as reporting limits or a botched migration. Mitigation: resolve in the spike before schema commitment.
• Write-path drift — API/CLI writers bypass Nova validation, producing dirty tags. Mitigation: model-level mutator and validation as the source of truth, not the field.
• Upstream abandonment — no patch for a Chrome/CSS regression or a Nova incompatibility. Mitigation: named owner and a one-day fork contingency.
• XSS in chip rendering — unverified; treat as a security-review item for any surface where tag text originates from untrusted input.

Degraded mode in all cases: a comma-separated text input, a few hours of work. That keeps every failure above in "annoyance" territory.

Ramp-up. Half a day for composer require, one fields() entry, nova:assets, and a light/dark render check — plus the 1–2 day spike if it's a new adoption with schema implications. Onboarding cost for a new engineer is low because the surface is small, but the decision-log entry and the naming of the fork owner are non-negotiable handoff artifacts; without them, the next engineer inherits an undocumented frozen dependency and no fallback. Budget the standing Nova-major testing as recurring, not one-off.