Laravel Nova Json Field Laravel Package

Product Decisions This Supports

• Build vs. buy for structured metadata in Nova admin panels. This package supplies a configurable JSON field with named sub-inputs and dependent-field syncing, which is the kind of capability teams otherwise hand-roll per model. It replaces a recurring "write a custom Nova field" line item with a Composer dependency.
• Feature scoping for admin/back-office CRUD. Any roadmap item that reads "let ops configure per-device / per-template settings without engineering" maps directly onto this field type. It is the enabling primitive behind device templates, integration config blobs, and per-tenant settings screens.
• Data-integrity risk triage. Release 1.2.2 fixes two defects that both manifested as silent data loss, not errors: filled-in values were dropped on save when the attribute had no prior stored value, and user edits were wiped whenever dependsOn re-synced. For a PM, this is a signal about where the package's quality risk concentrates — the save path and the reactive sync path — and justifies pinning versions and requiring a manual verification pass before each upgrade.
• Support-cost and trust modelling. The 1.2.1 → 1.2.2 delta is a bug-fix-only release with no breaking changes, no new features, and no deprecations. That means no migration work and no user-facing surface change; the decision is purely "adopt the fix," and the business value is the avoided tickets from field values silently disappearing.
• Upgrade sequencing. Because the fixes are drop-in and address lost user input, this release can ride along with any scheduled maintenance window rather than needing its own rollout plan.

When to Consider This Package

Adopt when:

• You are on Laravel Nova and need a JSON-backed attribute exposed as a structured, validated form rather than a raw textarea.
• Your domain has fields whose availability or defaults depend on another selection (e.g. device type → template name), and you want that dependsOn behaviour without maintaining custom Vue.
• You are pre-1.0 or already on 1.2.x — 1.2.2 has no breaking changes, so the upgrade is low-risk and specifically repairs a save-path defect.

Look elsewhere when:

• You are not on Nova, or you are planning a move off Nova — the value here is entirely Nova-coupled and does not port.
• You need first-class schema evolution, per-key indexing, or querying into the JSON. This field is an authoring surface, not a database strategy; if reporting or filtering on inner keys is on the horizon, model those keys as real columns.
• You require a vendor with a support contract, SLA, or an audited release cadence. This is a single-maintainer package; treat it as you would any small open-source dependency and budget for the possibility of forking.
• Your forms have highly custom validation or conditional logic beyond simple field-to-field dependency — the sync semantics (structure change vs. metadata change) are opinionated, and fighting them costs more than writing your own field.
• You cannot pin and test: the very bugs fixed here were invisible at the UI level, so an untested upgrade path is the real risk, not the package itself.

Given the release history, the practical criterion is: adopt at ^1.2.2, never float the constraint, and smoke-test save-after-edit on a fresh record and after a dependsOn selection change as part of the upgrade checklist.

How to Pitch It (Stakeholders)

For executives: This is a small, free add-on for our Nova admin panel that lets non-engineers edit structured configuration — device templates, integration settings, per-tenant options — through normal form fields instead of raw JSON. It removes a recurring custom-development cost and shortens the path from "ops needs a new setting" to shipped. The just-released 1.2.2 is a maintenance patch: no new scope, no breaking changes, no migration — it fixes two bugs where values users typed could be silently discarded on save. That was a data-loss bug, not a crash, so the patch is worth applying promptly; the work is a version bump plus a short manual verification, not a project.

For engineering: Bug-fix-only release, no API changes. Two fixes worth noting: (1) a null attribute cast to [] meant JSON.stringify sent an empty array and named form properties were dropped on first save — so records with no prior value could not be saved correctly at all; (2) the dependsOn watcher compared whole field objects, so any metadata change (e.g. selecting a template name) reset user edits — it now compares field IDs only and preserves values unless the field structure genuinely changes. Apply the patch, pin the constraint, and add both scenarios to the admin QA script since neither surfaces as an error to the user.