Nova Suneditor Laravel Package

Product Decisions This Supports

• Build vs. buy for admin rich text. This package turns a custom Nova WYSIWYG field from a 1–3 sprint engineering item into a composer require plus configuration. It lets you test whether richer authoring improves an editorial outcome before funding bespoke work.
• Roadmap unlock for content-heavy admin surfaces. It is a cheap enabling dependency for features where non-technical staff author formatted content: blog/marketing copy, help-center and policy pages, product descriptions, email bodies, landing pages. If authors currently paste HTML into a textarea, this is the fastest credible bridge.
• Content model direction — an explicit strategic fork. SunEditor is WYSIWYG HTML, not a block editor and not Markdown-first. Adopting it means storing formatted HTML blobs in a text column. That choice propagates into templating, localization, content reuse, search indexing, API output, and future editor migration. State it now rather than discover it later.
• Vendor and cost posture. MIT-licensed, client-side, no SaaS, no per-seat editor licensing, no external content API. Useful where procurement cycles, data residency, offline/internal deployment, or cost constraints shape tool choice.
• Tactical adoption vs. platform standardization. With 3 stars, 0 dependents, and no production references, the defensible PM decision is a time-boxed pilot with a documented fallback — not org-wide standardization. It supports a clear review gate rather than an open-ended commitment.
• Portability as an exit ramp. Because content is stored as plain HTML, replacing the editor later is a field-level swap, not a data migration. That lowers the cost of being wrong and is the strongest argument for experimenting now.

When to Consider This Package

Adopt when all of these hold:

• You are already running Laravel Nova in production. The package is inert outside Nova, so this is a prerequisite, not a preference.
• Authors are internal staff producing HTML content; you do not need real-time collaboration, inline comments, track changes, or AI-assisted writing.
• You need a rich-text field this sprint or this quarter, and a short spike plus configuration is acceptable effort.
• You accept a small, likely single-maintainer dependency, and are prepared to pin the version, read the field class, and fork under MIT if maintenance stalls.
• You will own server-side HTML sanitization. The package stores what the editor emits; XSS defense is your responsibility.
• You can tolerate a feature-flagged fallback — textarea or an existing field — for rapid disablement if a Nova upgrade breaks it.

Look elsewhere when:

• You need support SLAs, security-patch guarantees, or a vetted/audited dependency. The adoption signals — 3 stars, 0 dependents, no production references — represent real bus-factor and upgrade-fragility risk.
• Your content model is structured (blocks/JSON) rather than HTML. A block editor or Markdown field is the better fit, and retrofitting structure later is expensive.
• You need advanced authoring: collaboration, block composition, DAM/media-library integration, or built-in sanitization guarantees.
• You are not on Nova. Evaluate Tiptap, Lexical, Editor.js, or the equivalent Filament field instead.
• Your CSP or asset pipeline cannot tolerate a third-party editor bundle, or image uploads are required and you are unwilling to own the endpoint, storage, MIME validation, and access control.

Before committing, get answers to: supported Nova/Laravel/PHP/Vue versions and whether composer.json enforces them; whether the package sanitizes anything or delegates entirely to the host app; the upload contract if media is enabled; whether editor options are full pass-through or partly hard-coded; how assets are delivered; and behavior across create, edit, detail, index, and read-only modes.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, reversible experiment that unlocks formatted authoring in the Nova admin without a custom build, SaaS licensing, or per-seat editor fees. It lets us validate whether richer content authoring moves an editorial or content-ops outcome before committing platform budget. The risks are manageable and explicit: a small dependency with no ecosystem pressure, so we pin it, keep a one-line fallback, and own server-side sanitization. Because content lands as plain HTML, replacing the editor later is a field-level change, not a data migration.

To engineering: Treat this as a small, owned integration, not a turnkey dependency. Install it only in Nova, centralize configuration in one base field subclass, pin the package version, and add server-side sanitization on save or resolve. Verify asset loading, detail/index/read-only behavior, CSP compatibility, and upload handling if images are enabled. Keep a feature-flagged fallback to Textarea and a documented review trigger: upstream inactivity, a SunEditor security advisory, a blocked Nova upgrade, or a shift toward structured content. The source is small and MIT-licensed, so forking is a cheap escape hatch if maintenance stalls.

To product/editorial stakeholders: This gets authors out of raw HTML textareas quickly, with a familiar toolbar and lightweight editor. It is best for internal staff producing standard formatted content — not for collaboration, block-based page building, or heavily governed publishing workflows. We should use it to test whether better authoring improves throughput or quality, then decide whether to standardize, replace with a block editor, or build custom.