Nova Values Field Laravel Package

Product Decisions This Supports

• Repeatable-value UX vs. relational modeling. When a content type needs a simple ordered list of strings — bullet points, tags, aliases, SKUs, steps, email addresses — this field lets you ship JSON-array storage in a single Nova line instead of standing up a child table, migration, policy and relationship manager. That is a genuine roadmap accelerator for admin-only, low-cardinality data.
• Build vs. buy vs. fork. The package is essentially a thin subclass of Nova's built-in KeyValue field with keys stripped out. That makes it more a reference implementation than a dependency, and a useful input to the decision "do we write 30 lines in-house instead of adopting an unmaintained package?"
• Back-office investment scope. It supports calls about how much authoring polish to buy for internal users: this is roughly an afternoon of work for a visible editor improvement, with zero change to the customer-facing product.
• Data-model hygiene review. Its existence is a prompt to audit existing JSON key => value columns that never actually needed keys, and decide whether simplifying them is worth the migration.
• Dependency and risk register. Archived status, 6 stars, 0 dependents and no downstream consumers is a concrete data point for an "allowed packages in the Nova layer" policy — pin, fork, vendor or inline.

When to Consider This Package

Consider it when:

• You are on Laravel Nova — it is a Nova field, not a general form component, and is useless outside that context.
• The attribute is a genuinely small, bounded, ordered array of scalars that never needs to be filtered, sorted, aggregated, joined or reported on in SQL.
• You want the editing experience now and are comfortable either forking it under your own namespace or reimplementing it, given it is archived.
• It is used for internal/admin data entry only, not user-facing input, so a broken editor is an operational annoyance rather than a customer incident.

Look elsewhere (or write your own) when:

• You need per-item validation, min/max counts, translations or searchable values. The field is a UI wrapper; all of that logic is yours to build.
• Values must be filterable in Nova lenses or reportable in BI. JSON arrays are the wrong storage — use a related model.
• Your supply-chain policy forbids archived dependencies. Six stars and zero dependents means no community safety net; a single maintainer walking away is the expected outcome, not the risk.
• You are not on Nova, or you are on a Nova major version outside the package's tested range. Verify compatibility rather than assuming it.
• You would be pulling it in transitively as a dependency of something else — vendor or inline it instead.

How to Pitch It (Stakeholders)

Executives: This is a small, free (MIT) admin-panel widget that lets editors manage simple lists — tags, bullets, aliases, SKUs — without us building new database tables for each one. It is a back-office UX nicety, not a customer-facing feature, so treat it as a maintenance item rather than a roadmap item. The one decision it actually warrants is governance: the package is archived with negligible adoption, so I recommend we treat it as a short internal field or a fork we control rather than an external dependency we have to track.

Engineering: It is a near-clone of Nova's KeyValue field with the key column removed — one JSON array attribute, no migrations, no meaningful service-provider complexity. The cost to replicate is trivial, which is why I would rather own it than inherit an archived package. If we do adopt it, pin the version, vendor it into the repo, and be explicit that validation, ordering constraints and filtering are all our responsibility — JSON arrays will not be queryable in lenses or reports.