Livewire Editorjs Laravel Package

Product Decisions This Supports

• Content model strategy: structured blocks vs. HTML blobs. Editor.js stores content as an ordered JSON array of typed blocks (paragraph, header, list, image, embed) rather than rendered HTML. This package is the Livewire↔Editor.js bridge that makes that model usable in a Laravel admin panel. Adopting it is implicitly a decision to store structured content — which pays off later for multi-channel rendering (web, email, mobile), search indexing, SEO control, content migration, and LLM/RAG ingestion. Choosing a WYSIWYG HTML editor instead is a different, harder-to-reverse decision.
• Build vs. buy for the editor surface. The package is thin glue: a Livewire component that mounts Editor.js, handles hydration/serialization of the block JSON, and wires up image/file upload endpoints and validation. That glue is genuinely fiddly (JS lifecycle hooks, Livewire re-render behavior, upload adapters) but bounded. Realistic build estimate for a competent Laravel dev is 3–8 days; this package gets you to a working prototype in under a day. The buy side is cheap in money (MIT, free) and — as of v1.5.0 — cheaper in maintenance risk than it was six months ago, though still not free.
• Roadmap input for admin/CMS/internal-tool work. If the roadmap includes a blog, knowledge base, help center, marketing CMS, or any authoring surface inside a Laravel app, this is a candidate component to slot in rather than spec a from-scratch editor epic. The v1.5.0 Laravel 10 support removes the most common framework-version blocker for teams on current LTS-adjacent stacks.
• Feature scoping for the authoring MVP. The package defines the achievable v1 surface: block types, drag-reorder, image upload, and now configurable upload folder targeting. Anything beyond that (collaborative editing, comments, versioning, block-level permissions, custom block plugins) is not covered and must be scoped as separate work — useful for cutting an over-ambitious editor spec down to size.
• Asset-storage architecture. The new per-instance image folder option is a small but real product lever: it lets you partition uploads by tenant, by content type, or by environment without forking, which affects multi-tenant admin decisions and CDN/bucket layout.
• Tech-stack constraint check. It only makes sense if the product is already committed to Laravel + Livewire. It is not a reason to adopt Livewire.

When to Consider This Package

Consider it when all of the following hold:

• You are on Laravel 9 or 10 — Laravel 10 support landed in v1.5.0. Laravel 11+ is not covered and would be your port to do.
• You are on Livewire 2, or are willing to validate/port for Livewire 3. The v1.5.0 release addresses Laravel framework support but says nothing about Livewire 3; assume Livewire 2 until you've verified or patched it.
• You need block-style authoring with a small, well-understood block set, not a full document suite.
• You accept low-activity, single-maintainer risk. The project is no longer dormant — v1.5.0 added Laravel 10 support, a configurable image folder (community contribution from a first-time contributor), and bumped Editor.js 2.22.3 → 2.26.5 — but there is still no support SLA, no published security policy, and no triage guarantee. Recommended posture: vendor or pin the dependency, monitor upstream, and be prepared to own it. Full fork-and-own is no longer mandatory, but is still the safe default for customer-facing or regulated work.
• You are comfortable owning the JS layer: custom blocks, upload adapters, and compatibility of third-party Editor.js tools against the now-newer Editor.js 2.26.5 runtime.
• You own output sanitization and block rendering yourself — the package does not solve rendering safety.

Look elsewhere or build in-house when:

• You are on Laravel 11+ or Livewire 3+ with a near-term upgrade on the roadmap; expect to port the component yourself.
• You need a supported dependency with an SLA or CVE response time — still a hard requirement this package cannot meet, notwithstanding the recent release.
• You need HTML output, server-side rendering of blocks, or sanitization guarantees out of the box. You will write the block renderer regardless.
• Your authoring needs are simple: a Markdown editor, a plain textarea with preview, or TipTap/ProseMirror may be a better fit-to-need and better maintained.
• You are not on Livewire — use Editor.js directly with your own framework adapter.
• You need collaboration, comments, versioning, or a large plugin ecosystem; those are out of scope here.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed integration that lets us put a modern block-based content editor into our Laravel admin in days instead of a multi-week build. The strategic value isn't the package — it's the content format: structured JSON blocks instead of opaque HTML, which keeps our content portable across web, email, search, and future AI features. The maintenance picture improved materially this cycle: a new release adds Laravel 10 support, configurable image storage locations, and an updated underlying editor, with an outside contributor involved for the first time. That said, it remains a single-maintainer project with no support contract, so the recommendation is to pin and vendor it, with a fork as the fallback, rather than treat it as a supported vendor dependency. Net: the same strategic upside, a lower and better-understood engineering cost, and a small residual risk we can absorb.

To engineering: Thin Livewire wrapper around Editor.js — component mount, block JSON hydration/serialization, upload wiring. MIT-licensed, modest star count, no meaningful downstream dependents. v1.5.0 (new) adds Laravel 10 support, a configurable image save folder, and bumps bundled Editor.js from 2.22.3 to 2.26.5. Before adopting: confirm Livewire version compatibility (v3 is still unaddressed in the changelog), regression-test any third-party Editor.js tools against 2.26.5, review the upload endpoint for validation and authorization, and own output sanitization and block rendering on our side. Budget ~2–4 days to harden and pin, versus ~1–2 sprints to build the equivalent. Vendor or mirror upstream so a future stall doesn't block us; treat upstream as a maintained-but-thin reference we can take over.