Json Laravel Package

Technical Evaluation

Architecture fit. armincms/json is an admin-surface artifact, not a platform component: a Laravel Nova field that renders a JSON editor bound to an Eloquent attribute, plus a thin set of Eloquent casting helpers for nested keys. It carries no domain logic, no background processing, and no request-path footprint for end users. That is the TPM's central framing — a failure here degrades an internal operator's workflow, not customer traffic. Fit is a hard gate on two conditions: (1) Nova is the sanctioned admin framework in the current and next planning horizon, and (2) the requirement is genuinely arbitrary JSON. If the need is a known schema of a dozen keys, Nova's built-in KeyValue field or a bespoke field wins on maintainability, validation, and permissions at comparable effort.

Integration feasibility. Mechanically a one-line Composer require plus a field declaration in a Nova resource. The friction is version drift: last release 2020-06-18 places it in the Nova 2/3, Laravel 6/7, PHP 7.x era. Nova 4 moved the field layer to Vue 3 and Nova 5 tightened constraints further, so composer why-not armincms/json will likely block resolution on a modern estate — and a forced constraint override can still fail at render time because the Vue component contract changed. With 25 stars and 0 dependents, there is no public evidence of anyone running this against current Nova. We would be first, in production, alone.

Technical risk.

• Abandonment is realized, not theoretical. Single maintainer, no release in 4+ years, no changelog, no disclosure channel. Assume zero upstream fixes for the dependency's life.
• Compatibility drift. PHP 8.1–8.3 deprecations, Nova major-version field API changes, and Laravel's evolving JSON casting (array, json, AsArrayObject) are all unpatched — and will surface as upgrade-time blockers, not steady-state noise.
• Data integrity. A raw editor that writes the string straight through without schema validation permits silent, semantically wrong JSON to persist and break every downstream reader of that column. This is the highest-severity class: quiet, data-level, and expensive to unwind.
• Security surface. Admin-authored JSON re-rendered unescaped is a stored-XSS vector, requiring review of the field and downstream consumers.
• Licensing is clean. MIT permits forking, internal redistribution, and closed modification — the escape hatch that makes the risk manageable.

Key questions.

1. Which Nova majors are in the estate today, and at +12 months? This is the gating decision.
2. Does the field validate or normalize JSON before save, or persist raw input verbatim?
3. How does it interact with existing Eloquent casts and MySQL JSON vs TEXT columns — is there double-encoding under an array cast?
4. Is there a test suite, and does it run on our PHP and CI matrix?
5. What is the actual requirement — arbitrary JSON, or a bounded schema we can model properly?
6. Who is the named owner, and do they have Vue/Nova front-end skill or only backend Laravel?
7. Are audit, permission, or change-history requirements a raw editor structurally cannot satisfy?

Integration Approach

Stack fit. Assumes Laravel + Eloquent JSON columns + Nova. The write path is the subtle hazard: Nova fields typically set the attribute directly, so an array cast may double-encode while a json cast may mask a malformed payload. Verify in a scratch resource before any real table is touched.

Migration path. Do not take a direct dependency on the vendor package. Two routes, both of which reframe the decision from "adopt an abandoned package" to "vendor a small piece of MIT code":

• Fork into an internal namespace via a VCS repository entry, preserving MIT attribution and pinning the version.
• Inline the field class into app/Nova/Fields/ — likely a single class. Cheaper to own, harder to upstream, entirely appropriate at this size.

Compatibility. Run composer why-not armincms/json first; that one command decides whether this is a one-hour or one-week task. Then maintain an explicit matrix — Nova N-1/N, PHP 8.1/8.2/8.3, MySQL and PostgreSQL JSON columns, create and update paths — as a tracked artifact, not tribal knowledge.

Sequencing.

1. Spike (1–3 days). Branch install, wire to one low-risk resource (settings, metadata, feature flags), confirm read/write, cast interplay, and escaped rendering.
2. Decision gate (1–2 days). Compare against KeyValue and a custom field. Arbitrary JSON → proceed to fork; bounded keys → stop and use the built-in.
3. Harden (1–2 weeks). Fork, add JSON-schema validation on save, review escaping, add cast-interplay tests, wire CI to the Nova matrix.
4. Pilot (one sprint). One team, one resource, monitored for malformed-save incidents and admin complaints.
5. Roll out or retire. Expand only on a clean pilot; otherwise replace with the custom field and archive the fork. Book a named review date tied to the next Nova upgrade.

Operational Impact

Maintenance. The code is small; the maintenance is entirely ours. With no upstream to absorb Nova 4/5 or PHP 8.x changes, the fork must be explicitly slotted into the platform upgrade cycle. An unowned fork is worse than a dependency: it fails silently during a Nova upgrade and becomes a mid-migration blocker. Fund one owner and a standing line item, or do not adopt.

Support. No vendor, no SLA, no changelog, thin documentation. Support means one internal engineer who has read the field source and the Nova field API. Record that as a named single point of failure in the risk register rather than leaving it implicit.

Scaling. Negligible from a systems standpoint — it is a form control, with no effect on throughput, queue depth, or API latency. The real constraints are human and payload-sized: very large JSON blobs inflate admin page weight and are miserable to edit, and database JSON columns have practical size limits. Neither rejects the package, but both argue for a policy: enforce a size cap and a "one sub-document, not a whole config tree" rule.

Failure modes.

• Composer constraint conflict blocks a Nova upgrade mid-migration (highest likelihood).
• PHP 8.x deprecations surface as warnings or fatals in the admin panel.
• Malformed JSON saved without validation, breaking downstream readers (highest severity — silent, data-level, needs backfill remediation).
• Stored XSS via unescaped rendering of admin-entered JSON.
• Field renders but does not persist — cast or attribute-name mismatch — producing an apparent no-op, eroded admin trust, and a ticket queue.
• Fork drifts from upstream with no merge path; acceptable only if permanent ownership is explicitly accepted.

Ramp-up. Low for a Laravel developer: an afternoon to integrate and read the class. The non-obvious cost is fork maintenance — editing a Nova field means touching the Vue component and Nova's front-end build, a narrower skill than backend Laravel and often absent on the team. Plan for one engineer able to own both halves, or accept in writing that the fork will only ever receive backend-side patches and that any front-end break is a stop-the-line event.

TPM recommendation. Do not adopt as a dependency. If JSON editing in Nova is on the roadmap, allocate a bounded effort — days, not weeks — to fork or rebuild the field internally with validation, escaping review, tests, and CI. That converts an unmaintained third-party risk into a small, owned internal asset with a named owner. Scope usage to trusted internal users editing low-risk metadata; keep it away from customer-facing configuration, anything requiring audit trails or field-level permissions, and anything where a silent malformed write would be expensive to unwind. Treat the package as source material in a build-versus-adopt comparison, not as a strategic platform bet.