Filament Editorjs Laravel Package

Product Decisions This Supports

• Build vs. buy for the editor surface. If we already run Filament for admin, this package is a candidate to satisfy "block/structured content editing" without writing a custom field. The decision it informs is whether we spend engineering weeks building a block editor or adopt a third-party field and take on its risk.
• Content model: JSON blocks vs. HTML blob. Editor.js outputs structured JSON (paragraphs, headers, lists, images, embeds) rather than a single HTML string. That choice propagates into our API shape, mobile rendering, full-text search indexing, and front-end templating. This package makes the block model cheap to try in the admin, which is where we should test it before committing the storage contract.
• Feature roadmap for authoring workflows. Relevant if the roadmap includes marketing pages, blog/articles, documentation, help center, or any editorial surface where non-engineers publish. It is not relevant to transactional forms or short free-text fields.
• Per-content-type tool selection. Editor.js block plugins mean we can scope exactly which blocks a given content type allows (e.g., no embeds for help articles). That is a product decision about editorial guardrails, not just an engineering one.
• Internal tooling velocity. For a small team on Filament, the value is days saved per admin screen versus a bespoke editor component.
• Ownership/exit risk. With 18 stars, 0 dependents, and a low composite health score (~1.96), one of the decisions this informs is whether we are comfortable vendoring or forking a small package into our repo — i.e., it becomes "build" with a head start rather than "buy."

When to Consider This Package

Consider it when:

• The stack is Laravel + Filament (verify version compatibility — Filament majors move fast) and we want an Editor.js field in a form schema.
• The product needs genuinely block-structured content: articles, landing sections, docs, changelogs.
• The editing population is small and internal — a handful of content editors, not thousands of external authors.
• We are prepared to own it: read the source, pin the version, and be ready to fork. A single-maintainer package with no dependents is a spike candidate, not a platform.
• We already have, or will budget for, the downstream work this package does not do: safe block-to-HTML/React rendering on the front end, image upload/storage configuration, sanitization of embed blocks, and search indexing of JSON content.
• Time-boxed evaluation is possible: install, validate image uploads, XSS handling of raw HTML blocks, localization/RTL, and behavior across the target Filament version before any commitment.

Look elsewhere when:

• Procurement requires vendor support, SLAs, or a maintained release cadence. Zero dependents and low adoption mean we are effectively the maintainers.
• Requirements include real-time collaboration, comments, track changes, or high-fidelity WYSIWYG — consider Filament's built-in RichEditor (Tiptap-based) or a hosted editor (CKEditor, TinyMCE) instead.
• Content is simple — short descriptions, notes, titles. A textarea or basic rich text field is cheaper and safer than a block editor.
• The content must be authored in multiple surfaces (a React app, a mobile app, the admin). Then pick a headless/portable editor contract rather than a Filament-specific wrapper.
• Strict accessibility or compliance obligations exist and we do not have capacity to audit the editor UI and its plugin ecosystem.

How to Pitch It (Stakeholders)

Executive summary. This is a small open-source MIT plugin that drops a block-style editor (Editor.js) into Filament admin forms, storing content as structured JSON instead of an HTML string. It is cheap to trial and removes a chunk of custom admin-UI work if we are heading toward editorial content — marketing pages, articles, documentation. The caveat is maturity: ~18 GitHub stars, no downstream dependents, a single maintainer, and a low health score in our assessment. Recommendation: fund a short, time-boxed pilot rather than an adoption; assume we may fork or replace it, and keep Filament's built-in RichEditor as the fallback. The real cost is not the plugin — it is the front-end block renderer and content-schema decisions behind it.

For engineering. Treat it as a thin wrapper we can read in an afternoon. The integration questions are compatibility with our Filament version, how it handles image uploads and storage disks, how raw HTML/embed blocks are sanitized, and how block JSON is versioned when the tool set changes. Pin the version, vendor the source if adopted, and write the renderer and schema migration path as our own code.

For content/product. It enables structured, reusable content blocks with editorial guardrails per content type. It does not give us collaboration, comments, or approval workflows — those remain separate roadmap items.