Ux Editorjs Laravel Package

Product Decisions This Supports

• Rich-text / block-editor feature in Symfony back-office surfaces. The EditorjsType form field plus EditorjsAdminField (EasyAdmin) means a content-authoring feature can be scoped as "install a bundle and configure a form field" rather than "build a JS editor integration." That materially changes the estimate for any roadmap item involving article, page, or marketing-copy editing.
• Build vs. buy on the editor layer. The bundle ships 16 first-party tool mappings (Header, List, Paragraph, Image, Code, Quote, Warning, Table, Delimiter, Embed, Marker, Inline Code, Checklist, Link, Raw HTML, Underline), 11 community tool DTOs, and 3 block tunes. Buying the DTO/glue layer and contributing upstream is cheaper than owning an equivalent abstraction in-house — but only if you were going to pick Editor.js anyway.
• Structured content vs. freeform HTML. Block-based content (Editor.js output is JSON, not HTML) is a product decision in itself: it enables re-rendering the same content across web, email, and mobile, and it makes content queryable/migratable. This package makes that decision cheap enough to trial; the alternative JSON-to-HTML pipeline is still yours to build.
• Image upload / asset handling. A built-in upload controller with local filesystem, Flysystem (S3/GCS/Azure/SFTP), and a UploadHandlerInterface escape hatch covers the most commonly underestimated part of an editor story. Configurable max file size and MIME allowlist means the security baseline is config, not code.
• Front-end toolchain consolidation. AssetMapper and Webpack Encore both supported; Stimulus-based, no custom JS to maintain. Relevant if the roadmap includes "reduce bespoke JS surface area."
• Caveat on this assessment's framing: the request framed this as a Laravel/PHP package, but the release is a Symfony UX Bundle (Symfony 6.4/7.x/8.x, symfony/stimulus-bundle, Twig forms). It is not Laravel-native. For a Laravel codebase, treat this as reference architecture and a source of design lessons, not a drop-in dependency — budget a real port (Blade component, Livewire instead of Live Components) or use Editor.js directly.

When to Consider This Package

Adopt (trial / internal use) when:

• The product is on Symfony 6.4, 7.x, or 8.x with PHP ≥ 8.1 and Stimulus Bundle ≥ 2.9.1, and forms are Twig/EasyAdmin-driven.
• You need a block-style editor, not a classic WYSIWYG — and you accept JSON content storage.
• The team has limited or no front-end JS capacity; "zero JavaScript required" is the actual value proposition.
• You need multiple editors per page, Live Component compatibility (data-live-ignore), or image uploads to cloud storage without writing a controller.
• The use case is internal tooling, admin CMS, prototypes, or a spike where a breaking change in a minor release is a scheduling inconvenience rather than an incident.

Look elsewhere / do not adopt when:

• Stack is Laravel. No first-party support; the value is Symfony-specific (form types, EasyAdmin, Twig). Using Editor.js directly with a thin Blade/Livewire wrapper is the honest comparison.
• You need API stability. This is v0.1.0, explicitly experimental, with no backwards-compatibility guarantee between releases. Anything customer-facing, multi-tenant, or on a long upgrade tail should wait for a 1.0 or be vendored/forked with a pinned constraint and owned migration budget.
• You need an enterprise support contract, security SLA, or CVE response commitment. None is offered; this is a single-maintainer early-stage project.
• Accessibility is a hard requirement. Editor.js's contenteditable/block model has known screen-reader and keyboard-navigation limitations; the bundle does not claim to solve them. Verify against WCAG obligations before committing.
• You need HTML output natively, server-side rendering of editor content, or a mature plugin ecosystem with versioned contracts.
• You cannot own sanitization. The Raw HTML tool is a stored-XSS vector by design. Adoption is conditional on a sanitization policy (allowlist sanitizer on save and/or render) and a CSP. If nobody owns that, do not enable the tool — or the package.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, early-stage open-source Symfony bundle that plugs a professional block editor (Editor.js) into standard Symfony forms. The commercial case is avoided engineering cost: it replaces what is typically several weeks of bespoke JavaScript and upload plumbing with a form field and configuration, and it includes cloud storage support and a sensible file-upload security baseline. The risk is maturity — it is v0.1.0 and explicitly pre-stable, with no compatibility guarantees and no support contract. Recommendation: approve as a low-cost trial inside internal/admin tooling only, with a pinned version and a named owner; do not put it on a customer-facing or revenue-critical path until it reaches a stable release or we have forked it.

To engineering:

• It is Symfony, not Laravel — if this came up in a Laravel context, the realistic options are a thin in-house wrapper around Editor.js, or porting the DTO/enum tool-configuration pattern, which is the genuinely reusable idea here.
• The design is sound and testable: enums/DTOs for tool config, CustomTool for arbitrary ecosystem tools, AbstractTool for our own, TuneInterface for block tunes, and JS events (editorjs:options, editorjs:connect, editorjs:change) for lifecycle hooks.
• Pin the exact version (0.1.*), vendor or fork if we ship it, and expect breaking changes on every bump. Treat upgrades as scheduled work, not incidental.
• Two things we must own regardless: HTML sanitization for the Raw HTML block and any user-authored content, and output rendering (Editor.js emits JSON; block-to-HTML/Markdown rendering is our code, not the bundle's).
• Image upload is pluggable — start with UploadHandlerInterface against our existing storage abstraction rather than adopting the bundled controller wholesale, so we keep authz and virus-scanning in one place.
• Verify accessibility against our actual obligations before this reaches an end user; do not assume the editor's defaults satisfy them.

Decision requested: approve a timeboxed spike (one form, one admin screen, pinned version) with a go/no-go review against accessibility, sanitization, and upgrade-cost criteria.