Nova Items Field Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-panel UX. A "list of tags / emails / steps" input is the kind of field every internal tool eventually needs and no one wants to own. This package converts a recurring 3–10 day custom Vue field build into a composer require, and that decision recurs on every new Nova resource you ship.
• Data-modeling decisions. It standardizes "list of scalars" as a JSON column. That is a real architectural commitment: cheap to add, painful to query, filter, aggregate, or report on later. Adopt it deliberately for low-cardinality, display-oriented lists (tags, bullet points, contact emails, procedure steps) — not for anything the business will want to search, join, or count.
• Platform upgrade sequencing. Requirements are PHP ^8.4, Laravel ^11–13, Nova ^5. Adopting this package is downstream of an upgrade decision, not independent of it. It can serve as a low-risk forcing function / proof point for the PHP 8.4 + Nova 5 migration, or it can be blocked by it.
• Roadmap unblocking. Drag-to-reorder, per-item inline validation, min/max constraints, and chips-vs-rows display modes remove a backlog of "the admin UX is clunky" tickets without consuming a sprint of frontend capacity.
• Localization commitments. English and French labels ship out of the box and are publishable — relevant if French-language admin surfaces are on the roadmap.
• Migration off the legacy fork. If you are on blendbyte/nova-items-field or dillingham/nova-items-field, this is a supported successor with a documented migration table, which turns a "we maintain a stale fork" risk into a scheduled upgrade task.
• Feature-level scope calls the field makes for you: dependsOn (conditional fields), copy-to-clipboard, datalist suggestions, count-badge index views. Useful as a checklist when specifying adjacent admin fields.

When to Consider This Package

Adopt when:

• You are on (or committed to) Nova 5 / Laravel 11+ / PHP 8.4+. This is a hard gate — teams on PHP 8.2/8.3 cannot use it at all.
• You need to edit scalar lists stored in a JSON column: tags, keywords, emails, steps, bullet points, aliases.
• You currently maintain a hand-rolled items field, or depend on one of the older forks, and want a maintained replacement with a migration guide.
• Per-item validation matters — inline, per-row error messages are a genuine support-ticket reducer versus a single "invalid array" error.
• Your team has no spare Vue/Nova-tooling capacity and would otherwise defer the field indefinitely.

Look elsewhere when:

• You are not on Nova 5 (Nova 3/4, or Filament/Livewire stacks — different ecosystem entirely).
• The data needs to be relational or queryable: anything you will filter, join, aggregate, report on, or expose via API should be a child table, not JSON.
• Items are structured objects, not scalars (e.g. {label, url, icon}) — that is a different field type.
• You need rich per-item behavior: relations, file attachments, per-item permissions, or searchable/filterable index columns with real database indexes.
• Vendor concentration is a blocker: this is a v1.0.0 rewrite by a small studio, with no stated support SLA. Confirm license terms, release cadence, and issue responsiveness before making it load-bearing.
• Requirements churn risk is high — pinning to PHP 8.4+ narrows your hosting and CI options.

Trial-then-commit pattern: pilot on one or two low-traffic resources, verify the JSON shape against your export/reporting needs, then standardize.

How to Pitch It (Stakeholders)

To executives: This is a small, cheap, well-tested component for our internal admin tool that replaces custom code we would otherwise build and maintain ourselves. It removes roughly a sprint of frontend work per year across admin screens and eliminates a class of "invalid input" support tickets through per-row validation. Cost is one Composer dependency; the risk is contained because it is a single form field — if we abandon it, we change the field, not the architecture. The one caveat to note: it requires our platform to be on PHP 8.4 and Nova 5, so it should be sequenced after (or used to justify) that upgrade.

To engineering: It is a modern Laravel Nova 5 rewrite of the well-known nova-items-field, with the quality signals we actually ask for — 100% PHP and JS coverage, mutation testing at MSI ≥ 80%, PHPStan level 8, Pint, ESLint/Prettier, and a CI matrix across PHP 8.4/8.5 × Laravel 11/12/13 × Nova 5. API is idiomatic: Items::make('Tags')->chips()->suggestions([...])->rules('max:10')->itemRules('string', 'max:255'). It gives us array-level and per-item validation, min/max counts, drag-and-drop with keyboard accessibility, configurable index/detail presentations, dependsOn, and publishable i18n. Data lands in a JSON column, so treat it as a presentation field — if a list needs to be queried or reported on, model it as a related table instead.

Decision requested: Approve trialing it on one internal resource, contingent on the PHP 8.4 / Nova 5 baseline; confirm license terms and pin the version.