Nova Editor Js Laravel Package

Technical Evaluation

Architecture fit. This package is a capture component, not a content platform. It wires Editor.js into a Laravel Nova field and round-trips content as structured JSON ({ time, blocks, version }). Everything that makes that content useful — a server-side renderer, sanitization, block normalization, a plain-text shadow for search, schema versioning — is downstream work the team owns. Architecturally, that is an acceptable fit only if the product already runs Nova and the org accepts that adopting this field implicitly commissions a rendering pipeline. The package itself is thin (a Vue field component plus a config file mapping Editor.js tools); treat "thin" as both the appeal (small surface to audit and fork) and the risk (little upstream gravity).

Integration feasibility. Install is trivial: composer require, php artisan vendor:publish, add a json column, cast it array, wire the field on one resource. The genuine integration work is the two undeclared hard dependencies: (1) a renderer — editorjs-php server-side or editorjs-html client-side — and (2) an HTML sanitizer for raw/HTML blocks. Both are effectively mandatory and neither is supplied. Feasibility is high if scoped as a two-to-three-week mini-program (spike, renderer, sanitizer, normalizer, deploy hardening), not as a one-day drop-in.

Technical risk. The risk profile is elevated for a low-signal dependency (92 stars, 0 dependents). Key exposures:

• Nova major churn. Nova's field API shifts across majors (3→4→5). With zero downstream dependents, no one else catches regressions first. Budget 1–3 engineer-days per Nova major and expect to vendor the package into packages/ within a year.
• Asset publish. A missing public/vendor bundle yields a blank editor with no console error — the #1 production-vs-local failure. This is a deploy-pipeline risk, not a code risk.
• Stored XSS. Raw HTML blocks and unsanitized tool output are the sharpest edge; sanitize at write time, not read time.
• Silent content loss. Unknown block types are dropped by most renderers. Without an explicit unsupported-block renderer plus logging, a tool removal quietly deletes paragraphs.
• Tool version pinning. Individual Editor.js tools pin peer versions of core; a single upgrade can break the editor mount with an obscure console error.
• Concurrency. Single-editor surface, last-write-wins; two admins overwrite each other with no warning.

Key questions to resolve before commitment.

1. Which Laravel and Nova majors are we on, and does the package's tested matrix cover them?
2. Who owns the renderer, sanitizer, and normalizer — same team as the Nova resource, or a shared platform team? Staffing this is the gating decision.
3. What are the content consumers: web only, or web + mobile API + email + search index? Multi-consumer means normalize at write time, not per-client renderer forks.
4. What is the media disk/CDN contract, and does the package config's disk match what the frontend serves from?
5. Do editors need custom blocks? If yes, confirm whether the source registers tools via config or hardcodes them — this is the most common "we can just add one tool" surprise and it changes the estimate materially.
6. Is a 1–3 day fork budget per Nova major acceptable to the org, or does this need a maintained alternative?

Integration Approach

Stack fit. The package assumes Laravel + Nova + a JSON column + a frontend that can consume either structured JSON or rendered HTML. It slots in cleanly where the product keeps content in the same admin as business data rather than standing up a second CMS. Fit is poor if Nova is being phased out, or if the content surface is headless with multiple clients that would each need their own JSON renderer.

Compatibility matrix to verify in the spike.

• Laravel and Nova versions vs. the package's supported range.
• Editor.js core and individual tool peer pins — lock the toolchain, test mount after any single tool upgrade.
• PHP version and the renderer library (editorjs-php) requirements.
• Deploy pipeline: vendor:publish must run in every environment and stage public/vendor assets; the existing pipeline almost certainly does not do this today.
• Nova field API surface for read-only/displayUsing — needed for the detail/index views, which are not useful as editable surfaces.

Migration path. Do not point this field at an existing text/longtext column containing HTML or Markdown — Editor.js will replace the value with its JSON envelope on first save and silently destroy legacy content. Instead:

1. Add a nullable json column (body).
2. Cast it array on the model.
3. Add a body_text shadow column populated by the same save observer, so search, previews, and Nova index columns don't parse JSON at query time.
4. For existing content, run a one-off transformer to produce initial JSON blocks, or scope the field to new content types and leave legacy content on a separate, read-only HTML representation.
5. Preserve Editor.js's version and add your own schema marker alongside it if you mutate the contract.

Sequencing (recommended program).

1. Spike (1–2 engineer-days). Install, publish, author a heading + paragraph + list, dump the raw column in tinker, render it on a staging Blade page with editorjs-php. This is the decision gate: if rendering is painful, stop.
2. Renderer + sanitizer. Small service/Blade wrapper with try/catch and visible fallback; HTML purifier in the write path.
3. Normalizer + shadow column. Model observer that drops unknown blocks, strips empties, validates known types, sanitizes raw HTML, and writes body_text.
4. Deploy hardening. Asset publish in every environment; post-deploy smoke test that loads a Nova edit screen and asserts the editor mounts.
5. Disk/CDN config. Settle before any author uploads — retrofitting after the fact is painful.
6. Tool set per field. Expose only blocks the renderer and editors support; override at field level where the API allows, so a "marketing page" and a "short note" can have different vocabularies.
7. Roll out field by field. First on a low-risk resource, then expand as the renderer and toolset stabilize.

Operational Impact

Maintenance. The package will need vendoring into packages/ within roughly a year, with a 1–3 engineer-day budget per Nova major and a periodic toolchain upgrade review. The renderer, sanitizer, and normalizer are permanent internal code, not package responsibilities — staff them as such. Pin Editor.js tool versions in a lockfile and treat any tool bump as a testable change. The 92-star, 0-dependent profile means no downstream population catches regressions; the org's own smoke test is the only safety net.

Support. There is no enterprise support and no strong public maintenance signal. Internal ownership must be explicit — a named team on the hook for Nova upgrades, the renderer, and editor questions. Expect recurring editor-level support: paste-from-Word formatting questions (enable a paste-cleaner tool if the content team lives in Word), missing-block confusion when a tool is removed, and image upload disk confusion. Document the block vocabulary and the "unsupported block" placeholder behavior so editors can self-serve.

Scaling. Editor.js JSON is typically 2–4x larger than equivalent HTML and costs a parse+render per request. Cache rendered HTML keyed on the record and bust on save; that converts a per-request parse into a per-write cost. For read-heavy surfaces, the cached HTML is the fast path and the JSON remains the re-renderable source of truth. For multi-consumer content (web + API + email + search), normalize to HTML/Markdown at write time and store both forms — otherwise every consumer needs its own Editor.js JSON renderer, multiplying surface area. Search must go through the plain-text shadow column, not the JSON.

Failure modes and controls.

• Blank editor in production — assets published but not staged in the deploy; control: post-deploy smoke test that loads a Nova edit screen.
• Silent block drops — unknown or removed block types disappear; control: explicit unsupported-block renderer emitting a visible placeholder and logging.
• 500s on malformed JSON — one truncated row takes down a page; control: try/catch with a logged fallback to raw text.
• Stored XSS — raw HTML blocks rendered unescaped in the admin or public site; control: purifier in the save path.
• Last-write-wins overwrites — concurrent edits, no locking; control: document the behavior, add a lock for contended content, or accept the risk explicitly.
• Empty-wrapper divs — Editor.js emits blocks: [] not null; control: coalesce both cases in the renderer.
• Silent legacy data loss — pointing the field at an existing HTML column; control: greenfield column only, backfill via transformer.

Ramp-up. A single engineer can complete the spike in 1–2 days and reach production-ready in roughly 1–2 weeks including the renderer, sanitizer, normalizer, shadow column, and deploy hardening. Plan a parallel half-day for editor onboarding on the block model and toolset. The critical ramp-up risk is treating the package as a drop-in; the realistic framing is a small program with the package supplying only the editing UI and JSON round-trip.