Json Laravel Package

Product Decisions This Supports

• Feature scoping for admin tooling: Informs whether to expose raw JSON editing in Laravel Nova for settings, metadata, feature flags, localization bundles, integration payloads, or dynamic schemas — versus funding structured forms with validation, audit trails, and field-level permissions.
• Build vs. buy (small, bounded): Frames a narrow decision for internal admin capability. Given a single Nova field class, a day-or-two internal build or vendor-fork is usually cheaper over a two-year horizon than owning an unmaintained dependency. The realistic choice is "fork it," not "adopt it."
• Roadmap risk allocation: Appropriate only as a low-cost stopgap for internal operations tooling. It should never underpin customer-facing workflows, billing-adjacent configuration, or anything where a silent malformed write is expensive to unwind.
• Use-case fit: Strongest where trusted internal users need to inspect and edit genuinely arbitrary JSON. Weak-to-unusable where the requirement is a known schema of ~10 keys (Nova's built-in KeyValue field wins), or where schema validation, audit history, or non-technical editors are required.
• Scope verification before estimation: The package metadata is internally inconsistent — it is tagged as "a Laravel Nova field," while the description markets broader Eloquent JSON-casting helpers and dot-notation access with "no migrations required." Do not size roadmap work off the description. Read the source and confirm whether it is one Nova field or a model-layer utility; the estimate and the risk profile differ materially between those two readings.
• Migration and upgrade planning: If already present in the estate, treat the next Nova/Laravel/PHP upgrade as a scheduled decision point — verify, fork, replace, or absorb into app/Nova/Fields/. Unowned, it becomes a mid-migration blocker rather than a gradual degradation.
• Prioritization framing: Position it as source material, not a platform dependency. The PM decision is simply whether a lightweight JSON admin capability justifies owning a small MIT-licensed fork with a named maintainer.

When to Consider This Package

• You are already committed to Laravel Nova as the sanctioned admin framework. If the roadmap points to Filament, an Inertia/Blade back office, or API-only tooling, fit is zero regardless of code quality.
• You have verified compatibility first, against your actual Nova, Laravel, and PHP versions. Last release was June 2020 — the Nova 2/3 and PHP 7.x era. Nova 4 moved fields to Vue 3 and Nova 5 tightened constraints, so expect Composer to refuse resolution on a modern stack.
• The need is genuinely arbitrary JSON, not a bounded set of keys. Otherwise use Nova's built-in KeyValue field or a small bespoke field.
• The audience is trusted internal users doing low-risk editing — settings, metadata, feature flags, debugging payloads — with server-side validation and authorization wrapped around the field.
• You are willing to fork or inline it under MIT (attribution preserved, version pinned) and assign a named owner for compatibility testing, escaping review, and Nova upgrade cycles.
• You can absorb the front-end skill requirement. Editing a Nova field means touching the compiled Vue component and Nova's build — a narrower skill than backend Laravel, and frequently absent on a given team.

Look elsewhere or build internally if: you need active maintenance, modern Nova compatibility, schema-aware editing with validation UX, audit logging, fine-grained authorization, customer-facing reliability, or a dependency with community adoption. With 25 stars, 0 dependents, and no release since June 2020, default to treating it as unmaintained unless you validate and own it.

How to Pitch It (Stakeholders)

Executive summary: armincms/json is a small MIT-licensed Laravel Nova field for editing JSON in an admin panel. It is not a strategic platform dependency, and the adoption signal is weak — 25 stars, zero dependents, no release in over three years, single maintainer. Treat it as an unmaintained utility or, better, as MIT source material we can vendor.

Recommendation: Do not take a direct dependency. If JSON editing in Nova is on the roadmap, allocate a small bounded effort — measured in days, not weeks — to fork or rebuild a thin internal field with server-side validation, escaping review, tests, and CI. This converts an abandoned third-party risk into a small, owned internal asset and protects the admin experience at low cost. Scope it strictly to trusted internal users editing low-risk metadata.

Engineering pitch: Run composer why-not armincms/json against the target Nova and PHP versions — that single command decides whether this is a one-hour or one-week task, and it is the gating question for the whole decision. If it resolves, fork into an internal namespace or inline the class into app/Nova/Fields/, add JSON-schema validation on save, review output escaping for stored-XSS risk, and test the cast interplay (array cast double-encoding vs. json cast masking malformed input) before it touches a real table. Name one owner who can handle both the PHP and the Vue halves, and set a standing review date tied to the next Nova upgrade.

Product pitch: Use it only for internal, low-risk admin workflows where raw JSON editing is acceptable and admins are technical. Do not use it for customer-facing configuration, anything requiring auditability or field-level permissions, or anything where a silent malformed write would require a data backfill to unwind. The pilot is one team, one resource, one sprint — expand only on a clean run.