Nova Key Value Laravel Package

Technical Evaluation

Architecture fit hnassr/nova-key-value is a single-purpose Laravel Nova field package: a PHP Field subclass plus a compiled Vue component, registered through a service provider and published via nova:publish. Architecturally it is a thin adapter over Nova's field contract and adds no backend services, queues, or storage of its own — it simply serializes an arbitrary key/value map into a JSON column. That makes it cheap to adopt in principle, but its fit is entirely a function of Nova version: the last release (June 2019) places it in the Nova 1.x / early 2.x, Vue 2, PHP 7.1–7.3 era. Against Nova 4.x/5.x (Vue 3, Vite-based asset pipeline, revised Field API) it is not a plausible fit. Critically, Nova has shipped a first-party Nova\Fields\KeyValue field since the 2.x line, so this package is functionally redundant for the overwhelming majority of use cases — it is a build-vs-borrow decision where "build" already exists in the vendor product.

Integration feasibility Composer will likely install it without error on a modern stack; the failure surfaces at runtime and at upgrade time. Expected friction: a composer.json PHP/Laravel constraint pinned to ^7.x that conflicts with PHP 8.2+ projects; a published JS asset built against Nova's legacy Mix pipeline that will not load under Nova 5's asset handling; and Vue 2 component syntax that Nova 4+ cannot mount. Feasibility is therefore effectively binary — feasible only on a frozen, end-of-life Nova 1.x/2.x installation, and infeasible everywhere else.

Technical risk

• Abandonment risk: realized. The repository is archived. There is no security-response path, no issue triage, no PHP 8 compatibility work, and no route to a supported Nova release. Every future fix is ours.
• Upgrade ceiling. Adopting this package on any currently supported stack is a dead end; it becomes a blocker the moment the Nova major version moves, and it competes for the same Composer resolution space as Laravel/PHP upgrades.
• Data-shape coupling. Persistence is a JSON blob whose exact shape (associative map vs. list of {key, value} objects, ordering, null/empty handling) is defined by this package and not by the native field. That shape outlives the package and must be migrated deliberately.
• Low signal. 18 stars and a 0.19 score indicate essentially no production usage to draw failure data from; there is no community to validate edge cases.

Key questions

1. Which Nova major version is in production today — is this evaluation even live, or already moot?
2. Does the first-party Nova\Fields\KeyValue cover the requirement, including validation, ordering, and display? (Almost certainly yes.)
3. What is the exact JSON shape currently stored, and how many rows/columns are affected?
4. Is any behavior being relied on that the native field lacks — custom key whitelisting, per-key validation, cast-to-model attributes?
5. Is there a maintained fork or a sibling package with recent releases, if the native field genuinely falls short?

Integration Approach

Stack fit

• Target stack (Laravel 10/11, PHP 8.2+, Nova 4/5): no fit. Do not integrate.
• Legacy stack (Laravel 5.7/5.8, PHP 7.1–7.3, Nova 1.x): fits, but that stack is itself EOL and unpatched — the package's risk is additive to an already-unacceptable baseline.
• Any greenfield or mid-life project should treat the native KeyValue field as the default and this package as a non-option.

Migration path

1. Confirm parity: enumerate every behavior the current field provides and map it to Nova\Fields\KeyValue (or ->rules(), ->keyValue() options, ->resolveUsing()).
2. If parity holds, the migration is a field-swap plus a data-shape normalization migration for any rows written in the package's format.
3. If parity fails on a narrow point, write a small in-house field extending the native one — realistically 1–2 developer-days, fully owned, no archived dependency. This is cheaper than resurrecting a seven-year-dormant package.
4. Remove the dependency and unpublish its assets; delete the published Vue component from resources/js so it cannot be silently reintroduced.

Compatibility The hard incompatibilities are the Vue 2 component model (Nova 4+ is Vue 3), the asset pipeline (nova:publish + Mix vs. Nova 5's Vite tooling), and the PHP Field API surface across major versions. There is no shim worth building for a field this small.

Sequencing (a) Version audit of Nova/Laravel/PHP → (b) two-day parity spike against the native field → (c) data-shape audit and migration script → (d) field swap behind a feature branch → (e) QA on create/update/detail/index views and on existing records → (f) dependency and asset removal → (g) document the JSON contract. Do (b) before (c): if parity fails, the shape migration changes entirely.

Operational Impact

Maintenance Zero upstream maintenance by definition — the repo is archived. Total cost of ownership is 100% internal from day one, against a capability the vendor already ships. That is a poor trade for a field with no differentiating logic.

Support No maintainer, no issue tracker activity, no security advisories. If it breaks during a framework upgrade, the incident is unbounded in duration because there is no upstream to escalate to. Escalation path is "a senior engineer reads the Vue component and rewrites it," which should be priced in up front, not discovered mid-upgrade.

Scaling Storage and runtime impact is negligible — a JSON column, no extra queries. The real scaling constraint is analytical: key/value JSON is effectively opaque to indexing and reporting. If any of these keys ever need filtering, sorting, aggregation, or joins, this schema will not carry it, and the workaround is a painful normalization later. Decide now whether the data is display-only or queryable; if queryable, model it as real columns.

Failure modes

• Silent field render failure (blank or console error) after a Nova upgrade — discovered by an admin user, not by CI.
• Published asset 404 after a Nova asset-pipeline change.
• JSON decode errors on legacy rows with malformed or partially-written payloads.
• PHP 8 type/deprecation errors from unmaintained 7.x-era code.
• Composer resolution conflicts that block unrelated Laravel or PHP security upgrades — the most damaging failure, because it holds the whole application back.

Ramp-up Learning curve is trivial (it is a small field), but the knowledge is orphaned: nobody outside the team has written about it, and any bug requires reading source. Before removing or migrating, document the persisted JSON shape and the exact key set in use — that documentation is the only durable artifact this package will leave behind.

Recommendation: Do not adopt. Use the first-party Nova KeyValue field; where it falls short, build a small owned field. If already installed, treat removal as a scheduled dependency-hygiene task rather than an open evaluation — the archived status and the existence of a native equivalent together make this a decision, not a trade-off.