Nova Trumbowyg Field Laravel Package

Product Decisions This Supports

• Converting a "we need a rich-text editor" backlog item into a configuration change. This package drops a Trumbowyg WYSIWYG into any Laravel Nova resource backed by a TEXT/LONGTEXT column. For internal content surfaces — blog posts, help-center articles, policy pages, product descriptions, email templates — it turns a custom-field project into a one-line addition to a resource. It is a scope-reduction lever, not a product differentiator.
• Build vs. buy on a commodity capability. Formatted text is table stakes. A free MIT-licensed field that satisfies "editors need bold, links, lists, and headings" frees the sprint for the workflows and data model that actually differentiate. The decision that genuinely needs PM sign-off is maintenance ownership, not licensing cost.
• Roadmap sequencing for internal tooling. A low-effort enabler that unblocks editorial workflows and CMS-lite modules now, while deferring investment in a richer authoring stack (structured content, media libraries, collaboration) until content volume or editor sophistication truly demands it. Communicate it explicitly as a bridge, not a destination.
• Scope containment for a single-field need. When one or a few Nova resources need basic formatting, this covers the requirement without dragging in a heavier editor platform or a headless CMS.
• Explicit risk budgeting in the build-vs-buy conversation. With 6 stars and 0 dependents, adoption is a conscious choice to accept a package the team may end up owning (pin, patch, fork). The near-zero-cost-today versus possible-fork-or-migration-later trade-off belongs in the decision record, not buried in a pull request.
• A small, implicit reaffirmation of Nova as the admin layer. Because this only runs inside Nova, adopting it nudges the platform decision. Fine when Nova is settled; a flag to pause if the team is actively evaluating Filament or a custom stack.
• A hedge against lock-in by design. The field stores plain HTML, so the data model survives whatever editor comes next. That makes the "migrate later" option cheap and defensible in a roadmap review.

When to Consider This Package

Consider it when:

• The application already runs Laravel Nova, and the problem statement is "add a WYSIWYG to this field," not "choose an admin panel."
• The need is basic rich text — inline formatting, links, lists, simple headings — for internal or low-stakes content where Trumbowyg's feature set is sufficient.
• The team values MIT licensing, no vendor lock-in, and a small install footprint over commercial support and a formal SLA.
• You are prepared to treat it as forkable and pinnable. A 6-star, zero-dependent package has thin maintenance margin; someone must own upgrades or a fork if upstream stalls. Verify release cadence against actual tags before trusting the listed release date.
• The surface is internal-facing, so editor polish, accessibility auditing, and mobile parity carry lower stakes than customer-visible authoring. Note Trumbowyg is jQuery-based — reintroducing jQuery into a jQuery-free Vue 3 Nova must be acceptable and must not collide with other Nova add-ons or your CSP.
• You accept that HTML sanitization is your responsibility. The field stores what the editor emits; plan a server-side pipeline (e.g., HTMLPurifier) on write and on render, since the editor can be bypassed via devtools or API calls.
• You need per-locale editors. It behaves like a standard Text field, so translatable columns via spatie/laravel-translatable work with one editor per locale — a concrete roadmap unblocker for localization.

Look elsewhere when:

• You need advanced authoring — collaborative editing, media and image libraries with asset management, reusable content blocks, tables, markdown round-tripping, or structured content modelling. Reach for a TipTap/ProseMirror-based Nova field or a dedicated CMS integration.
• Accessibility, mobile editing, or brand-consistent UX are hard requirements. Validate Trumbowyg's output and behavior against your standards before committing.
• You require vendor support, a security SLA, or a predictable release cadence. Zero dependents means effectively no production validation; assume you are the maintainer of last resort.
• The application is not on Nova, or the team is reconsidering the admin layer. Do not let a field package anchor a larger platform choice.
• Content operations are becoming strategic — multi-channel publishing, localization at scale, editorial governance. At that point a headless CMS or structured content model is the right investment, and this field is the wrong foundation to build on.
• Your admin enforces a strict CSP and you cannot accommodate inline init or jQuery's eval surface without material rework.

How to Pitch It (Stakeholders)

To executives: We can deliver formatted-text authoring in our admin panel this sprint at essentially zero license cost. It's an MIT-licensed Laravel Nova field that gives internal teams a familiar toolbar — bold, links, lists — on the content types already in the backlog, without a custom-field project or a CMS procurement. The trade-off is ownership: the package is small and lightly adopted, so we should pin the version, own our HTML sanitization, and treat it as a tactical bridge rather than a platform commitment. If content needs grow to structured publishing or collaboration, we migrate deliberately — and because the stored data is plain HTML, that migration stays cheap. Recommended next step: a one-resource pilot with a defined "good enough" checklist before wider rollout.

To engineering: Drop-in Nova field wrapping the Trumbowyg editor, configured through a JSON-safe options array best centralized in a base field class so resources stay declarative. Two things we own: a server-side sanitizer on write (the field stores whatever HTML it receives) and CI validation that the editor actually mounts after Nova upgrades — silent failure to render is the common breakage. Watch for jQuery reintroduction into the Nova bundle, CSP conflicts from inline init, and dark-mode styling mismatches. Pin to 2.0.*, keep all extension in our own subclass rather than vendor/, and keep a documented one-line rollback to the native Text/Textarea field. Budget roughly a sprint-day for the spike, sanitizer wiring, and smoke test; assume we may fork if upstream goes quiet.