Filament Jsoneditor Laravel Package

Technical Evaluation

Architecture fit. Unchanged. The package remains a Filament form field (Filament\Forms\Components\Field) with a Blade view and an Alpine/JS wrapper around the jsoneditor front-end library, i.e. a sanctioned Filament extension point for admin surfaces already on Filament panels. It is still purely presentation-layer with no persistence opinion: the value round-trips as a JSON string into a json/text column and all validation stays in Laravel. Fit is strong if the consuming admin is Filament; still a non-starter for plain Blade or non-Filament Livewire forms.

Integration feasibility. Slightly harder than before, and now version-dependent. Release 5.0 is a major bump whose only documented change is Laravel 12 support (PR #41). A major version bump for a framework-support change almost certainly means raised dependency floors — likely PHP 8.2+, illuminate/* ^12, and plausibly a Filament v4 requirement or a v3 drop. That makes "one composer require" true only if our host app is already on Laravel 12. On a Laravel 10/11 + Filament v3 app we must pin ^4.2 and accept that the 4.x line is now effectively frozen. Effort stays 1–3 engineer-days on a compatible stack; add ~1 day if the bump forces a Filament upgrade or a fork-and-relax of composer.json.

Technical risk. Prior risks stand; the release shifts their weighting.

• Bus factor 1 (partially mitigated). Still one maintainer and a small user base (25 stars, 0 dependents), but 5.0 is evidence of continued maintenance rather than abandonment. Treat as a vendored dependency you may have to own — the fork contingency is now more likely to be exercised for constraint reasons than for abandonment.
• Breaking-change opacity (new, elevated). A 4.2.1 → 5.0 bump with a one-line changelog gives no deprecation notice, no migration guide, and no statement of what was dropped. We cannot infer from the notes whether Filament v3 is still supported in 5.0.
• Filament major-version coupling (unchanged, but now entangled). Package major versions appear to track framework major versions. That means our Filament v3→v4 and Laravel 11→12 upgrades and this package's version are coupled into a single, sequenced change rather than independent ones.
• Frozen 4.x line (new). Security or jsoneditor fixes are likely to land only on 5.x. Staying on 4.2.1 means we own backports.
• Asset pipeline. Still reliant on prebuilt resources/dist; theming or option changes may force a Node/Vite build we maintain.
• Livewire state sync. Editor instances vs. Livewire DOM morphing remains a known fragility class; needs wire:ignore-style hardening and testing on deferred/lazy fields.
• No schema validation. Editor gives syntax feedback only; business-rule validation must be server-side.
• Data size and security. Multi-MB documents degrade browser performance; JSONEditor's import/file affordances should be explicitly disabled for untrusted admin input.

Key questions.

1. What are the exact composer.json constraints in 5.0 — PHP, illuminate/*, filament/*, livewire/*?
2. Does 5.0 still support Filament v3, or does it require v4? Does it drop Laravel 10/11 outright or just stop testing them?
3. Is the bundled jsoneditor version bumped in 5.0 (security-relevant), or is this purely a constraint change?
4. Will 4.x receive security or dependency fixes now that 5.0 exists, and for how long?
5. Are assets pre-built and version-tagged in the 5.0 tag, or does a clean install require npm run build?
6. Does it still render validation error state, dark mode, and disabled/readonly consistently with native fields?
7. What is the maintainer's responsiveness to issues, and do we have an internal fork plan with a named owner?
8. Does it survive CSP without unsafe-eval, and does it spawn blob workers?

Integration Approach

Stack fit. This is now a two-track decision rather than a single answer.

• Laravel 10/11 + Filament v3 (likely current state): pin ^4.2, treat as frozen, and budget for owning patches.
• Laravel 12 + Filament v4: adopt ^5.0 only after confirming Filament v4 support and re-running the full compatibility matrix. Persist to a json column with an array/AsArrayObject cast, but keep the string as the canonical field value so the component stays swappable. Node toolchain only needed if we fork or theme.

Migration path. Straight swap from a textarea + ->rules(['json']) or a code-editor field; no data backfill since the stored shape is unchanged. Rollback to a plain textarea remains a one-line component change, which continues to de-risk adoption. The new consideration is the package migration: 4.2.1 → 5.0 should be sequenced as part of the Laravel 12 upgrade, not as a standalone dependency bump.

Compatibility checks. Resolve 5.0 in a throwaway Laravel 12 skeleton and diff the resulting dependency graph against 4.2.1 (composer why-not) to enumerate exactly what the major bump drops. Verify against the pinned Filament minor; confirm interaction with a custom viteTheme; test Livewire morph behavior on repeated saves; confirm CSP headers permit the editor's worker strategy; test light/dark and RTL if in scope.

Sequencing.

1. Diff 4.2.1 vs 5.0 composer.json and resources/dist — establish whether this is a constraint-only release or carries a jsoneditor bump.
2. Spike in a scratch panel with a representative worst-case payload (size, nesting) on the target Laravel/Filament combination.
3. Define validation: server-side json rule plus a schema check (opis/json-schema) if the payload has a contract.
4. Security/asset review — local hosting, SRI, CSP, disable file-import affordances.
5. Wrap as an internal App\Filament\Fields\JsonEditor extending the package class, with the version constraint declared in one place, so no resource references the vendor class directly.
6. Add browser-level tests (Dusk/Playwright) for edit → save → reload, run against both the 4.x and 5.x tracks if we straddle them.
7. Roll out behind a feature flag to one resource, then widen.

Operational Impact

Maintenance. Still low surface area, but the version matrix just doubled. Expect to hold either a pinned ^4.2 with an owned patch branch or a ^5.0 aligned to Laravel 12 — ideally not both for long. Budget ~1–2 days per quarter for framework-compatibility work, plus a decision point at each Laravel major: the package major now moves with it. MIT licence keeps the fork option open; the wrapper class remains the lever that bounds maintenance to one file.

Support. No vendor SLA; GitHub issues with a very small user base. The 5.0 release is a positive responsiveness signal but does not change the ownership model — internal ownership must be explicit and named. Document the wrapper as the internal API and the expected JSON shape as user-facing help text in the field. Add a note to the internal runbook recording which package major is bound to which Laravel/Filament major.

Scaling. Client-side only, so no server cost. The constraint remains payload size and editor count per page — enforce a server-side max: rule (e.g. 512KB) with a clear error, and limit multiple editors per form. Air-gapped environments require locally hosted assets rather than CDN.

Failure modes and mitigations.

• Dependency resolution fails after an unrelated composer update → build breaks on a transitive constraint. Mitigate with a committed lockfile, a pinned constraint, and CI that runs composer validate/why-not.
• 4.x goes unpatched for a bundled-editor CVE → known-vulnerable JS in admin. Mitigate with an annual (or advisory-triggered) dependency review and a documented fork procedure.
• Asset fails to load → field renders blank; a required field could submit stale state. Mitigate with server-side validation always on, asset 404 monitoring, and local hosting.
• Client accepts invalid JSON → confusing 422s. Mitigate with a syntax rule plus inline help.
• Livewire re-render detaches the editor → stale values on save. Mitigate with morph hardening and browser tests.
• Filament upgrade breaks the view → form render exception with page-level blast radius if widely used. Mitigate with the wrapper, a pinned constraint, and a feature-flag kill switch back to textarea.
• Upstream abandonment → we own security patches for the bundled editor. Mitigate with an annual dependency review and a documented fork procedure.

Ramp-up. Near-zero for Filament-fluent engineers on a compatible stack. Add a short internal note on the version matrix so engineers do not casually bump the constraint past our Laravel version. For support and content staff, roughly half a day: expected JSON shape, error semantics, and the textarea fallback path. Overall this remains a low-cost, low-ceiling convenience component — worth adopting narrowly where raw-JSON editing is a real admin need, not worth standardizing across the platform, and now with a clearer rule: adopt the package major that matches the framework major, and do not upgrade it ahead of the app.