Nova Suneditor Laravel Package

Technical Evaluation

Architecture fit. This is a narrow, single-purpose Nova field: a Vue component wrapper that mounts SunEditor inside the Nova form lifecycle and stores raw HTML in a model column. Architecturally it is a leaf dependency — it touches the admin presentation layer and one text column, nothing else. That is a good fit if and only if the platform is already Laravel Nova and the content model is deliberately "formatted HTML blob." It is a poor fit if the roadmap points toward structured/block content, JSON-based page composition, or Markdown-first authoring, because choosing this field is effectively a content-model decision that propagates into templating, search indexing, localization, and API output. The TPM read: this package settles a presentation-layer question cheaply and a content-model question expensively. Adopt it for the former, be explicit about the latter.

Integration feasibility. High. Installation is composer require plus a field class in a Nova resource; the surface area is small enough to read end-to-end in minutes. Realistic effort for a first working field is under a day; production-grade effort is 3–6 engineering days once you account for the work the package does not do: server-side HTML sanitization, an image-upload endpoint (storage disk, MIME validation, access control), CSP compatibility testing against the production policy, and verification of create/edit/detail/index/read-only rendering. Budget those as first-class line items, not a hardening pass. Two dependencies are non-negotiable before this reaches a public-facing template: a sanitizer (mews/purifier or equivalent) on save or resolve, and a column-size guard (max:65535 rule plus TEXT/MEDIUMTEXT).

Technical risk. Concentrated and well-understood, which is the good kind. The dominant risk is bus factor: 3 stars, 0 dependents, no production references, single maintainer. There is no ecosystem pressure keeping this in sync with Nova majors, and Nova upgrades are the primary compatibility event. Secondary risks: (1) XSS — the field stores whatever the editor emits, codeView allows arbitrary pasted HTML, and there is no built-in sanitization; this is a security defect waiting for an owner, not a bug in the package; (2) silent truncation — oversized HTML payloads against a TEXT column produce "saved but content disappeared," which surfaces as a support ticket rather than an error; (3) CSP breakage — SunEditor injects inline styles, so strict style-src policies break the UI in production while working fine locally; (4) options() pass-through fragility — powerful and untyped, so SunEditor upstream option renames break configuration silently. Mitigating factor: MIT license, ~200 lines, trivial to fork and pin. That converts "dependency risk" into "scheduled maintenance line item," which is a defensible trade.

Key questions to resolve before committing.

1. Which Nova/Laravel/PHP/Vue versions are supported, and does composer.json enforce those constraints or merely suggest them?
2. Does the package perform any sanitization, or delegate entirely to the host app? (Assume the latter; confirm.)
3. What is the upload contract if the image button is enabled — does the package ship an endpoint, or do we own controller, disk, MIME validation, and authorization?
4. How are assets delivered (bundled, published via nova:publish, CDN), and does that survive our CSP?
5. Are editor options full pass-through or partly hard-coded, and how does options() merge?
6. Behavior across all five modes — create, edit, detail, index, read-only?
7. Who is the named internal owner of this dependency, and what is the review trigger?

Integration Approach

Stack fit. Clean, with one hard gate: Nova must already be in production. The package is inert outside a Nova admin panel — there is no standalone Blade component or CDN build, so it offers no reuse path for a public-facing editor or a Filament admin. If Nova is present, fit is essentially zero-friction: SunEditor::make('Body', 'body') is a drop-in replacement for a Textarea field. If Nova is not present, this is the wrong evaluation entirely and the comparison set becomes Tiptap, Lexical, or Editor.js.

Migration path. Unusually cheap, and this is the package's strongest structural argument. Same column, same content type — existing Textarea or legacy-editor HTML flows straight through. Recommended sequence: (1) audit existing rows for size and malformed HTML (SELECT LENGTH(body) FROM posts ORDER BY 2 DESC LIMIT 10) before flipping anything; (2) run a one-off command that sanitizes legacy rows; (3) introduce the field behind a feature flag; (4) flip per-resource, not platform-wide. Because content lands as plain HTML, the exit migration is also a field-level swap rather than a data migration — that exit ramp is the real long-term value and should be stated in the decision record, not discovered later.

Compatibility. Pin the version explicitly ("webard/nova-suneditor": "1.0.*" or exact) — do not float. Treat every Nova major upgrade as a scheduled review item with a defined test: does the field mount, render, and round-trip HTML through save and reload. Keep a one-line kill switch in the resource so disablement is a config change, not a deploy:

env('USE_SUNEDITOR', true)
    ? RichText::make('Body', 'body')
    : Textarea::make('Body', 'body')->rows(15),

Sequencing. Recommended as a time-boxed pilot with a gate, not a standardization:

1. Spike (≤1 day). Install, mount one field on one resource, confirm assets load, confirm HTML round-trips through create → save → reopen → detail.
2. Harden (2–4 days). Sanitization pipeline, column-size guard, upload endpoint if media is in scope, CSP verification against the production policy.
3. Centralize. Subclass once (App\Nova\Fields\RichText) so toolbar policy and options([...]) live in a single file. Every resource references the subclass — never sprinkle ->options() across 40 resources.
4. Pilot (1–2 weeks). 2–3 internal authors, 1–2 content types, with the fallback flag live.
5. Gate. Ship broadly only if the pilot clears the review triggers below.

Review triggers — set these up front, don't drift. Upstream inactive >6 months; a SunEditor security advisory; a blocked Nova upgrade; or a strategic shift toward structured/block content. Any one of these returns the field to evaluation. Under MIT with a small surface, the fallback is a fork via a composer.json repositories entry — cheap enough that "maintainer goes dark" is not a blocking risk.

Operational Impact

Maintenance. Low steady-state, with two recurring obligations. First, Nova upgrade compatibility — the single highest-probability maintenance event, and one with no upstream patch guarantee. Second, sanitizer policy drift — as authors discover new paste sources, the sanitization ruleset needs review. Because all configuration lives in one subclass and all editor options live in one options([...]) array, a SunEditor or Nova bump is a single diff, not a grep across the resource layer. Assign a named owner; an unowned dependency with no ecosystem pressure is how these silently rot.

Support. No vendor SLA, no security-patch guarantee, no support contract — that is the explicit tradeoff for MIT and zero licensing cost. Internal support burden is best characterized as first-line triage by the adopting team, with expected ticket classes that are diagnosable rather than mysterious: "content saved but displays empty" (hydration — check onlyOnForms() or a resolveUsing callback swallowing the value; confirm the DB value via Tinker first), "content saved but empty in DB" (mass-assignment or fillUsing), "editor looks broken but works" (CSP blocking inline styles), "content disappeared on long posts" (column truncation). Document these four triage paths in the runbook and support load stays trivial. Procurement, data-residency, and offline-deployment constraints are all satisfied — client-side, no SaaS, no external content API, no per-seat editor licensing.

Scaling. Two axes, and only one is a problem. Author count scales fine — it's a client-side editor with no server cost per seat. Payload size does not scale gracefully: HTML blobs grow fast, a single pasted Word document with embedded base64 images can reach multiple megabytes, stall the browser tab, and exceed a TEXT column with silent truncation. Mitigations: enforce max:65535 (or lower) at the field level, set charCounter, tighten pasteTagsWhitelist to a strict allowlist (h1|h2|h3|p|ul|ol|li|a|strong|em|blockquote|pre|code|table|tr|td|th|img), and consider disabling image in favor of a media-library field if asset governance matters. If images are in scope, own the upload endpoint fully — validate image/* and size, store on a private disk, serve through an authorized route, never public/.

Failure modes. Ranked by likelihood × impact:

• XSS via stored HTML — highest impact, near-certain without a sanitizer. Mitigate server-side on save or resolve, consistently, and treat it as a launch blocker, not a hardening item.
• Nova major upgrade breaks the field — medium likelihood, medium impact, mitigated by version pinning plus the feature-flag kill switch.
• CSP breaks the editor UI in production only — medium likelihood, low-to-medium impact; test against the production policy, not local dev, and expect to need style-src 'unsafe-inline' scoped to the admin surface (or a nonce policy covering runtime injection).
• Silent column truncation — medium likelihood, high diagnostic cost because it looks like a data-loss bug rather than a schema bug.
• SunEditor upstream option rename breaks configuration — low likelihood, low impact, contained by centralizing options() in one subclass.
• Maintainer abandonment — low urgency, fully mitigated by MIT fork.

Ramp-up. Fast for engineers (read the field class in minutes; it's ~200 lines), moderate for authors. Two things drive author-side ramp: toolbar curation and paste behavior. Default paste from Word/Google Docs is liberal and imports inline styles that bloat stored HTML and break frontend CSS — set pasteTagsWhitelist deliberately and let the server-side sanitizer enforce it even if the client lets something through. Also verify the field's behavior on detail and index views before rollout: some Nova fields leak raw HTML or an uninitialized editor into non-form contexts, which is confusing for authors and looks like a defect. Use ->onlyOnForms() or ->showOnIndex(false) as needed, and confirm read-only rendering is safe given your sanitization choice.

Recommendation. Adopt as a time-boxed pilot with a documented fallback, not as a standardized platform dependency. It converts a 1–3 sprint custom Vue field build into a composer require plus configuration, and it lets you test whether rich-text authoring actually moves an editorial outcome before paying for bespoke work. The defensible position with 3 stars and 0 dependents is experimentation with explicit exit criteria — and because content lands as plain HTML, being wrong costs a field swap, not a data migration. Fund the sanitization pipeline and the CSP test as launch prerequisites; they are the difference between a cheap win and an incident.