Filament Editorjs Laravel Package

Technical Evaluation

Architecture fit

• The package is a thin Filament form-field wrapper around Editor.js, a block-based (JSON document model) editor. Architecturally it is a presentation-layer plugin: it contributes a Livewire-compatible form component plus JS/CSS assets registered through Filament's asset pipeline.
• Fit is good only where the host application is already Filament-based and content is stored as a JSON document blob (json column). It is a poor fit for teams that need structured, queryable, field-level content (e.g., per-block relational indexing) or that render content outside a PHP/Blade front end.
• It does not attempt to solve the hard half of the problem: server-side rendering/validation of block documents, media handling endpoints, and sanitization. Those remain the integrating team's responsibility.

Integration feasibility

• Low-to-moderate effort for the happy path: composer require, register the plugin on a Filament panel/service provider, add the field to a form schema, add a json (or longText) column. Realistically 1–3 days for a spike.
• The real cost is on either side of the field: (a) an upload endpoint for Editor.js Image/Attach tools, (b) a renderer for the stored block JSON on the read path, (c) validation rules that reject malformed block documents before persistence.
• Editor.js output is not HTML. Any existing WYSIWYG-derived content, sanitization pipeline (HTMLPurifier et al.), or search index over rendered HTML will need a new adapter.

Technical risk

• Maturity/adoption risk (high): 18 stars, 0 dependents, single maintainer, low composite score. Assume no meaningful community backstop. Treat as "source-available sample code" rather than a supported dependency until proven otherwise.
• Bus factor (high): one maintainer; no evidence of a release cadence or issue-triage SLA in the metadata. Fork-and-own is the realistic operating model.
• Version coupling (medium–high): the plugin is bound to both a Filament major (v3 vs v4 field/asset APIs) and an Editor.js major (block tool schemas change across majors). Two independent upgrade axes on a low-traffic package means breakage is likely to be discovered by you, not upstream.
• State-sync risk (medium): rich-text editors inside Livewire require careful JS/Alpine lifecycle handling (wire:ignore, re-hydration on morph, dirty-state sync). This is where thin wrappers typically fail in production (content loss on re-render, stale state after validation errors).
• Security/rendering risk (medium): stored JSON is attacker-influenced if any non-admin role can author. Output rendering, URL/link tool hrefs, and embedded HTML blocks are XSS surfaces; sanitization is out of scope for the package.
• Supply-chain/licensing risk (low): MIT license is clean; dependency tree includes Editor.js and its block tools (also permissively licensed). Pin and audit at install.

Key questions

1. Which Filament major is supported, and is there a stated compatibility matrix? Does it track Filament 4?
2. Which Editor.js version and block tools are bundled, and how are they pinned/upgraded?
3. Does the field handle Livewire re-render/morph correctly, and how is dirty state propagated on submit?
4. How are file uploads handled — is there a documented endpoint contract for Image/Attach tools, or is it left to the host app?
5. Is there any server-side validation or schema for the stored block JSON?
6. Is there a maintained fork or a credible alternative (e.g., a first-party or higher-adoption Filament rich-text/editor plugin), and what is the switching cost?
7. What is the maintainer's stated support intent — is this explicitly a personal-use package?

Integration Approach

Stack fit

• Requires: PHP/Laravel matching the supported Filament major, Livewire, and a front-end asset build that Filament can publish from. No Tailwind build step is needed by the host if the plugin ships compiled CSS — verify this, because uncompiled plugin CSS is a common trap.
• Fits if: admin/back-office content authoring inside a Filament panel, content stored as a JSON document, rendering done by your own Blade components or a headless consumer.
• Does not fit if: you need inline editing on a public-facing page, structured/queryable per-block data, or a no-JS-framework stack.

Migration path

• From a plain textarea: trivial — backfill a synthetic block document ({"time":…,"blocks":[{"type":"paragraph","data":{"text":…}}],"version":…}) so the editor opens with existing content.
• From a WYSIWYG/HTML field (TinyMCE, CKEditor, Trix): non-trivial. Requires HTML→Editor.js block conversion plus a legacy renderer path; run both renderers in parallel rather than attempting a big-bang rewrite.
• Keep the raw stored payload immutable and version-tagged. Rendering should tolerate unknown block types (render a placeholder, not an exception) so that an Editor.js upgrade never breaks old records.

Compatibility

• Pin the plugin, Editor.js, and Filament to exact versions in composer.json/lock; treat any Filament minor upgrade as a breaking change until smoke-tested.
• Confirm PHP version support and whether the package declares Laravel/Filament constraints at all — absent constraints means Composer will happily install it into an incompatible tree.
• Verify asset publishing works under the panel's asset strategy (published vs vendor:-served) and in production --no-dev builds.

Sequencing

1. Spike (1 week, timeboxed): branch-only install, one Filament resource, create/edit/render round-trip, Livewire re-render test, validation-error path, upload endpoint stub.
2. Decision gate: adopt, adopt-with-fork, or substitute. Decide before any schema migration is written.
3. Fork-and-vendor if adopting: take a pinned copy into a packages/ path or a private VCS, add your own tests, and own Editor.js upgrades explicitly.
4. Build the two missing halves: upload endpoint + block-JSON renderer + validation rule set. Schedule these as first-class work, not cleanup.
5. Pilot on one low-traffic content type; instrument author errors and content-loss reports.
6. Roll out resource by resource; keep the previous editor available behind a feature flag for one release cycle.

Operational Impact

Maintenance

• Expect to own it. Budget roughly 2–5 engineer-days per year for routine upkeep (Filament major upgrade, Editor.js major upgrade, block-tool updates) on top of the initial integration — and considerably more in the year a Filament major lands if the package is unmaintained.
• Add a smoke test that round-trips a stored block document through the field and the renderer; this is the single highest-value regression guard.
• Track upstream: watch the repo for releases, and pre-identify the substitution candidate so a dead-maintainer event is a planned swap, not an incident.

Support

• No vendor support, no SLA, no security disclosure process. Internal support means one or two engineers who have read the source. Document the fork, the pinned versions, and the upload/render contracts in your own repo.
• Treat it as tier-3 internal dependency in your service catalog with an explicit owner.

Scaling

• Runtime cost is client-side (Editor.js bundle) plus JSON payload size; server cost is negligible. Watch document size — large block documents inflate Livewire payloads on every round trip and can push against request limits.
• Media at scale is your problem: upload storage, image resizing, CDN, and orphan cleanup are all outside the package. Plan storage and retention before the first author uploads 200 images.
• No known horizontal-scaling concerns beyond standard Livewire payload and asset-caching practice.

Failure modes

• Silent content loss on Livewire re-render or partial morph — highest-severity failure; mitigate with wire:ignore/stable keys and explicit tests.
• Malformed or partially-saved JSON persisting because validation is absent — mitigate with a server-side block schema check and a NOT NULL + shape constraint at the DB or cast layer.
• Unrendered blocks after an Editor.js upgrade — mitigate with a defensive renderer and unknown-type fallback.
• XSS via stored block content (link hrefs, embeds, HTML blocks) — mitigate with output sanitization you own.
• Asset 404s in production after a deploy that changes the publish tag — mitigate with a post-deploy asset smoke check.
• Composer resolves into an incompatible Filament — mitigate with explicit constraints in your root composer.json, not reliance on the package's.

Ramp-up

• An engineer familiar with Filament and Livewire needs ~0.5 day to be productive; ~2–3 days to be confident modifying the JS bridge and the renderer.
• Non-Filament engineers need Filament fundamentals first — the plugin is not a shortcut past that.
• Required reading for whoever owns it: the plugin's field class and asset registration, Editor.js's document schema and block-tool API, and your own upload/render contracts. Keep that list in the repo README.
• Because adoption is near-zero, there is effectively no community knowledge to lean on; ramp-up cost is documentation you must write yourself.