Nova Editor Js Laravel Package

Product Decisions This Supports

• Admin authoring strategy — where content gets written. Choose between (a) block-based editing inside the Nova admin the team already runs, (b) standing up a separate CMS, or (c) commissioning a bespoke Nova field. This package makes option (a) a realistic near-term move: it is the shortest path from "we need better content editing" to a working Editor.js surface in Nova, without a new system or a new tool for editors to learn.

• Build vs. buy vs. adopt — a concrete "adopt" option. Against "build a custom Nova + Editor.js field," adoption trades a few weeks of engineering for a thin, low-signal dependency (92 stars, 0 dependents, niche maintenance). Frame it as a tactical bet, not a platform commitment: buy the capture layer, own the content contract.

• The content model decision (the real decision). The package forces an explicit product call: is content structured block JSON — where rendering, validation, sanitization, and schema versioning are downstream responsibilities we own — or an opaque HTML string? The package captures the choice; it does not solve it. Everything that makes content useful is ours.

• Roadmap enablement without a CMS migration. Unlocks blog posts, marketing/landing pages, knowledge bases, help centers, documentation, and richer product descriptions inside Nova — provided the rendering path is scoped in the same breath as the authoring path. A roadmap item that looked like a Q+ CMS project becomes a scoped engineering task.

• CMS-light product direction. Keeps content in the same admin as the rest of the business data, with a portable JSON representation, instead of bolting on a second system with its own users, permissions, and editorial model.

• Operational consolidation. Reduces tool sprawl: ops and content teams author where they already work. Cuts onboarding surface and any per-seat or license overhead for a separate editorial tool.

• Multi-channel distribution strategy. If the same content feeds a Blade site, a mobile API, an email, and a search index, this package's JSON-first model supports a "JSON as source of truth, normalized HTML/Markdown as the fast path" architecture — but it commits us to writing and maintaining that normalization layer ourselves.

• Dependency and risk posture. The niche profile should trigger an explicit maintenance, compatibility, and fork-budget review before it becomes roadmap-critical. Treat it as a "pilot, then decide" input, not a default-yes.

• Resourcing ownership. An undeclared but real decision: someone must own the renderer, sanitizer, block contract, and Nova-upgrade maintenance. This package is a capture component; the content platform around it is our build.

When to Consider This Package

Consider it when:

• The product already runs Laravel Nova, and the team wants Editor.js-style block editing inside Nova resources rather than a separate editorial system.
• Content genuinely benefits from structured blocks — headings, lists, images, embeds, code — rather than one undifferentiated rich-text field.
• Speed matters and the team is comfortable adopting a smaller ecosystem package instead of building and maintaining a custom Nova field.
• The field sits behind an internal admin surface, where a fallback, fork, or later replacement is acceptable if upstream maintenance stalls.
• Engineering can validate, before commitment: compatibility with the current Laravel/Nova major, Editor.js core and tool version pinning, media/disk configuration, and the asset-publish step in the deploy pipeline (public/vendor must be published in every environment — the single most common "works locally, blank editor in production" failure).
• A renderer plan exists in parallel — editorjs-php, editorjs-html, or a custom Blade/Inertia component — plus a sanitizer and a block allowlist. These are effectively undeclared hard dependencies the team must own.
• The integration is greenfield content with a new nullable json column, not an existing text/longtext column holding HTML or Markdown (Editor.js will overwrite legacy content on first save).

Look elsewhere when:

• The product is not on Laravel Nova, or Nova is being phased out or replaced. This package has no value outside that ecosystem.
• The team requires enterprise support, a strong public maintenance signal, or a large downstream population to catch regressions first. 92 stars and 0 dependents means we are the canary.
• Requirements include advanced editorial workflows — real-time collaboration, versioning, approvals, localization, complex media libraries — that a single-editor Nova field does not and will not own. Last-write-wins concurrency is the default.
• Content is consumed by multiple headless clients (web, mobile, search). Each consumer needs its own JSON renderer, multiplying surface area — only proceed with a write-time normalization strategy.
• A simpler WYSIWYG or native Nova text field suffices. Block JSON adds rendering, schema-versioning, sanitization, and migration complexity that must be justified by a real content need.
• Content is customer-facing and mission-critical with no internal fork or maintenance plan in place.
• The team cannot absorb the Nova major upgrade cost — budget roughly 1–3 engineer-days per Nova major, and expect to vendor the package into packages/ within a year so an upstream delay never blocks a release.

Gate the decision on a 1–2 day spike: install, publish assets, author a post with a heading, paragraph, and list, dump the raw JSON column, and render it on a staging Blade page with a server-side renderer. If rendering is painful, stop — the package gives you capture, and rendering is the whole job. Exit criteria: a green/red call on rendering effort and on Nova/Editor.js version compatibility.

How to Pitch It (Stakeholders)

Executive summary. We can bring modern, block-based content editing into the admin we already run — blog posts, docs, help center, marketing pages — without buying or building a CMS. This package is a Nova field that gives editors a clean Editor.js experience and stores content as structured JSON rather than raw HTML, so the same content can later be rendered to the website, apps, or email. It is a small, single-purpose dependency, not a platform: it handles editing, and we own rendering. The recommendation is a short, bounded pilot, not a permanent commitment.

For engineering. Thin surface area: a Vue field component, a config file listing enabled Editor.js tools, and image uploads routed through existing Nova disk configuration. Real work is ours and should be planned explicitly: a server-side renderer (editorjs-php or equivalent) with caching, a block allowlist/normalizer on save, HTML sanitization at write time (raw HTML blocks are a stored-XSS vector against both admin and public site), a plain-text shadow column for search and index previews, and envelope/schema versioning. Two operational must-dos: asset publishing in the deploy pipeline, and pinning Editor.js tool versions. Assume we fork or vendor the package within a year.

For the content/ops team. Fewer tools, fewer formatting accidents, and structured output that renders consistently across pages. Two honest caveats to set expectations early: paste-from-Word will look ugly unless we enable a paste cleaner, and two editors on the same record will overwrite each other — no locking.

Risks and asks.

• Risk: single-maintainer, low-signal dependency. Mitigation: internal admin only, vendor within a year, budget fork time per Nova major.
• Risk: rendering and sanitization become invisible scope. Mitigation: resource the renderer and normalizer as part of the same initiative, not a follow-up ticket.
• Risk: silent content loss from unknown block types or malformed JSON. Mitigation: explicit unsupported-block placeholder, try/catch fallback renderer, save-time normalization.
• Ask: approval for a 1–2 day technical spike with a go/no-go on rendering effort, plus engineering capacity for the renderer, sanitizer, and block contract.

Timeline framing. The install is trivial; the first real milestone is rendering the stored JSON back to safe HTML. Scope the pilot to one low-risk resource, one block vocabulary, and one staging page. Decide to expand, fork, or replace once that path is proven end-to-end.