Nova Json Wrapper Laravel Package

Product Decisions This Supports

• Schema strategy: normalized columns vs. a single JSON column. The package makes the "one JSON column" option cheap to implement in the admin UI, so it shifts the build-vs-buy conversation from "we can't afford that schema" to "that schema is a deliberate choice with reporting consequences." That is a data modeling decision, not a UI decision, and should be reviewed by whoever owns analytics and exports.
• Admin surface for flexible/heterogeneous attributes. Good fit for address blocks, notification preferences, per-tenant settings, CMS page metadata, or any grouped field set that is edited together and rarely queried by individual child field. Useful when the roadmap includes "more config knobs" without a migration per knob.
• Roadmap dependency on Laravel Nova. Last release Feb 2021 and zero dependents strongly suggest it targets Nova 3.x. If the roadmap includes a Nova 4/5 upgrade, this becomes a migration blocker to schedule, not a library to adopt. Treat the upgrade decision as the gate.
• Build vs. buy for small internal tooling. The package is a thin wrapper. The honest comparison is "adopt 12-star package with a 4-year-old release" vs. "spend ~a day writing the same field group with resolveUsing/fillUsing closures or a custom Nova field." For an in-house admin panel, the second option frequently wins on total cost of ownership.
• Vendor/audit posture. 12 stars, 0 dependents, no recent commits = no community backstop. If your policy requires maintained dependencies or a security review trail, this is a "no" on process grounds before it's a "no" on technical grounds.
• Reporting and data-portability requirements. Choosing JSON storage now constrains search, filtering, CSV exports, and BI tooling later. The decision this package enables should be paired with an explicit answer to "who will query these fields in 18 months?"

When to Consider This Package

Consider it when:

• You are on Nova 3.x and staying there for the foreseeable future.
• The grouped fields are presentation-oriented — edited together, rarely filtered or sorted individually, and not required in downstream reports.
• You need a fast prototype or internal admin panel where speed matters more than long-term support guarantees.
• Your team is comfortable forking and owning a small MIT-licensed package if it breaks; the code surface is small enough that this is realistic.
• You have a migration path in mind — either accept that this field group gets rewritten during the Nova upgrade, or encapsulate it so the blast radius is one form.

Look elsewhere when:

• You are on Nova 4 or 5, or plan to upgrade within the next two release cycles. Compatibility is unverified and the package has been dormant since 2021.
• Individual attributes need to be searched, sorted, filtered, indexed, or aggregated in SQL. Use real columns.
• You need maintained dependencies for compliance, SOC2, or procurement review.
• A first-party or DIY alternative covers the same ground: Nova's built-in JSON/KeyValue handling, per-field resolveUsing/fillUsing closures, or a ~100-line custom field. These cost more upfront and less over three years.
• The data is multi-tenant and high-volume, where a JSON blob invites inconsistent shapes and silent schema drift.

How to Pitch It (Stakeholders)

For executives (one paragraph): "This is a small, free, open-source add-on for our admin panel that lets us build dense edit screens without adding a database column for every input. It could save us a few days on configuration-style features. The catch is that it hasn't been updated since early 2021 and effectively has no user base, so nobody else is maintaining it. My recommendation is not to adopt it as a strategic dependency. If we want the capability, we should either budget a short internal build (roughly one engineer-day) or treat this package as a disposable prototype. Either way, the real decision it forces is about our data model: fields stored as JSON are cheap to add and expensive to report on later."

For engineering:

• Scope: groups multiple Nova fields into one JSON-backed column; thin wrapper around Nova field resolution.
• Risk profile: stale (Feb 2021), Nova 3.x-era, 12 stars, 0 dependents, MIT so forkable. No active maintainer.
• Recommendation: spike only. Validate against our Nova version in a branch; if it works, vendor/fork it into our own namespace so we control compatibility. Do not pull it in as an unqualified dependency.
• Prerequisite: agree on the JSON schema for each grouped field set and document it, since the database will not enforce it.

Decision requested: Approve a timeboxed spike, with a default of building the equivalent in-house rather than adopting.