Editorjs Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for block-based editing: Frames the real decision as "adopt a maintained editor integration" versus "build a thin wrapper." For a Laravel codebase the answer is the second — this bundle is a Symfony bundle, so the decision it informs is whether to copy its pattern (Editor.js form binding, JSON block persistence, server-side rendering) rather than install it.
• Content model / roadmap: Decides whether our product stores rich text as HTML or as structured JSON blocks. Editor.js and this bundle assume the block-JSON model, with rendering done server-side from that JSON. That choice shapes future features (block reordering, per-block analytics, template variations) far more than the package itself.
• CMS authoring experience: Supports a "modern editor" roadmap item — non-technical editors get a Notion-style block editor instead of a legacy WYSIWYG, which reduces malformed-markup support tickets and improves content portability.
• Platform upgrade planning: v1.4.0 adds Symfony 8 support. As a PM signal this is about vendor trajectory, not our roadmap — it tells us the upstream project is still maintained, but it has no bearing on a Laravel upgrade path (Laravel pins its own Symfony component versions transitively).
• Frontend stack decision: Clarifies that the editor is a client-side JS concern (npm/Vite assets) with a JSON contract at the boundary — not a PHP-package decision. That reframing moves budget from "backend integration" to "one frontend component plus validation."
• Use cases worth scoping: marketing/CMS pages, blog and documentation content, help-center articles — anything authored by humans and rendered read-only. Not a fit for collaborative editing, inline commenting, or media-asset-management-heavy workflows.

When to Consider This Package

• Consider the pattern (not the dependency) when: the product needs structured block editing, the team is Laravel-based, and we want a proven reference implementation of the Editor.js ↔ server contract — field serialization, JSON persistence, block-whitelist validation, and server-side rendering. Treat the bundle as documentation.
• Consider the actual package when: the application is Symfony-based, uses Symfony Forms and Twig, and needs Editor.js wired in without bespoke plumbing. In that case the form type and renderer are genuine time savers.
• Look elsewhere when: the stack is Laravel-first. There is no ServiceProvider, no publishable config, no Blade component, no facade — installing it yields an inert dependency and a foreign DI container we would have to reason about. Laravel does not boot Symfony bundles.
• Look elsewhere when: requirements demand a batteries-included WYSIWYG (tables, embedded media library, collaboration, track changes) or a large multi-vendor ecosystem. This is a single-maintainer bundle with concentration risk and no commercial support or SLA.
• Validate before committing either way: the sanitization and rendering path (stored JSON is user-generated content — XSS risk is real and must be handled server-side), the Editor.js JS version pinned, asset delivery (vendored vs. CDN/npm), and whether a maintained Laravel-native alternative covers the same need.
• Do not treat Symfony 8 support as a green light: it is a Composer constraint widening, not evidence of active feature development, and it says nothing about Editor.js JS version compatibility.

How to Pitch It (Stakeholders)

• Executives: A modern block-based editing experience is a small, bounded build — days, not a quarter — and this package is the reference design that de-risks it. We are not buying it; we are copying a proven pattern so we do not pay for a bespoke editor integration or inherit a single-vendor dependency we cannot upgrade with our own tooling.
• Engineering: The package is a Symfony bundle and therefore not consumable in our Laravel app. What we take is the architecture: mount Editor.js via a Blade component, post editor.save() JSON to a hidden input, persist to a json column behind a value-object cast, validate server-side against a whitelisted block-type schema, and render with an escaped per-block-type partial — never raw HTML interpolation. Estimated 150–300 lines we own outright, roughly a 2–3 day spike to prove end-to-end.
• Caveats to flag up front: (1) The real maintenance load is Editor.js block-tool churn, not this bundle — pin the JS version and upgrade deliberately. (2) Stored block JSON is untrusted input; strict server-side schema validation and escaped rendering are non-negotiable. (3) Enforce a payload size cap and block-count limit — large documents produce multi-hundred-KB request bodies. (4) Render unknown or retired block types as a safe placeholder rather than dropping them, to avoid silent content loss. (5) Upstream is one maintainer with GitHub-issues-only support; the block schema we document is the artifact that survives any future tool swap.