Laravel Nova Tiptap Field Laravel Package

Product Decisions This Supports

• Build vs. buy for admin rich text. This package is the "buy" (well, MIT-adopt) answer to a recurring build-vs-buy question: do we hand-roll a Tiptap/Vue field inside Nova, or drop in a maintained wrapper? At 2 stars and a single maintainer, it is really a borrow-with-a-fork-plan option — cheap to try, cheap to abandon, but not something to build a critical content pipeline on without an owner. It supports a decision to prototype rich authoring in days rather than weeks.
• Scoping where rich content lives. It answers — narrowly — the question "should editors author long-form content inside the Nova admin?" If yes, this is the shortest path. If the roadmap points toward authoring outside Nova (headless CMS, external editorial tool, non-admin users), this package does not support that decision and shouldn't be cited as a step toward it.
• Storage format as a product decision, not an implementation detail. The field forces an explicit choice between storing sanitized HTML and storing ProseMirror JSON. That choice constrains downstream product surface: HTML makes search, RSS, email digests, and existing Blade templates trivial; JSON preserves fidelity for re-editing but breaks LIKE search and requires a custom renderer. As PM, own this decision up front and write it down — it is the single most expensive thing to change later.
• Search and index UX. The recommended pattern — derive a plain-text excerpt on save in a model observer — is a product feature decision (what users see in Nova index tables, meta descriptions, search results), not just a performance tweak. It also keeps derived fields consistent across Nova writes, seeders, imports, and API writes.
• Use-case triage for content models. Good fit: blog bodies, policy/help pages, CMS blocks, internal documentation — content where "clean, structured formatting" matters and a slightly imperfect editor is acceptable. Poor fit: high-value regulated content, anything requiring custom nodes (callouts, embeds, footnotes) unless 2.x exposes a registration hook, and anything where "editor silently normalized my markup on open" is a support-ticket generator.
• Risk budget for a low-traffic admin surface. Because the blast radius is confined to Nova forms rather than the public site, this is a legitimate place to accept a small, single-maintainer dependency — provided the public render path is sanitized independently of the field.
• Roadmap input for editorial workflow. If the roadmap includes validation rules, max lengths, read-only/disabled states, or conditional (reactive) rich-text fields, treat those as open questions to verify in a spike before committing the feature to a release.

When to Consider This Package

Consider it when:

• The team already standardizes on Laravel Nova for admin authoring and just needs a modern WYSIWYG for a longText column.
• Content is admin-only, authored by a small internal group, and the field can be declared on one or two resources rather than everywhere.
• You're greenfield on the content type, or the legacy content is already clean HTML that Tiptap's schema will accept without loss.
• You can commit to an explicit storage-format + server-side sanitization policy (e.g., mews/purifier or symfony/html-sanitizer on save in an observer), with sanitization also enforced at render time as defence in depth.
• You're willing to pin ^2.0.1, read changelogs before bumps, and maintain a smoke test that the editor mounts in create, update, and detail views.
• You have — or will name — one internal owner who can read the Vue field component and the ProseMirror schema, because the fork contingency is real.

Look elsewhere when:

• Authoring is on a critical path or customer-facing, and you need a vendor SLA, security policy, or multi-maintainer governance. Two stars and a single-patch 2.x history do not support that.
• You need custom Tiptap nodes or deep toolbar control and 2.x doesn't expose an extension hook — you'd be forking resources/js/field.js on every release, converting a cheap dependency into a permanent merge cost.
• You must migrate large volumes of legacy content (Trix, Markdown, raw HTML with inline styles) into the field. Tiptap re-serializes on open and silently drops schema-invalid markup, so an unvalidated backfill risks unrecoverable content loss.
• Your Nova major version isn't confirmed supported with a pinned Tiptap major, or a Nova 4→5 upgrade is already on the near-term roadmap with no lockstep package upgrade path.
• Rich text needs to appear in reactive/dependsOn forms, where rich-text state plus conditional show/hide is a known source of flicker and lost edits.
• A commercial Tiptap-backed editor or a first-party Nova field is an affordable contingency and the authoring workflow is high-value enough to justify it.

How to Pitch It (Stakeholders)

To executives: We can add a modern rich-text editor to our Nova admin for essentially zero license cost (MIT) and roughly a week of engineering, versus several weeks to build and maintain the equivalent in-house. The scope is deliberately small: it only affects how internal staff author long-form content in the admin — it does not touch the public site, our APIs, or customer-facing flows. The real cost isn't the package, it's ownership: it's a small, single-maintainer open-source project, so we should treat it as a trial with a named internal owner and a fallback plan rather than a permanent platform commitment. Recommended ask: a one-week spike on a single low-risk resource, with a go/no-go decision before wider rollout.

To engineering: This is a Nova custom field wrapping Tiptap/ProseMirror. Integration is the standard Nova field contract — install, publish field assets, nova:publish, declare Tiptap::make('Body') on a resource — so no domain code changes. Three things need deciding before we write anything: the storage format (sanitized HTML vs. ProseMirror JSON), the sanitization point (server-side on save, in an observer or mutator, not just at render), and the version pins (package minor, Nova major, Tiptap major, all locked). The known failure mode is the editor failing to mount after an upgrade — 2.0.1's only changelog entry is exactly that fix — so our acceptance criteria for the spike are: editor renders in create, update, and detail views, and a round-trip (create → save → reload → render) preserves content. We should also derive a plain-text excerpt in a model observer so the Nova index doesn't blow out row height on raw HTML or JSON, and so search and meta descriptions don't depend on the editor's output shape.

To security/compliance: Editor output is user input. We will not rely on the field's client-side behavior as a security boundary. Policy: sanitize on save so dirty HTML never reaches the database, sanitize again on render as defence in depth, and add a CSP. Any existing legacy content must be validated before this field is pointed at it.

Known risks to state plainly: single maintainer and a young 2.x line (expect patch churn); Tiptap and Nova major upgrades will require lockstep package upgrades with no migration tooling; custom-node requirements likely mean forking the field component; and content normalized on first open may not survive a poorly planned migration. Each has a cheap mitigation — a mount smoke test, a round-trip test, pinned versions, and a sanitizer — and those mitigations are the actual deliverable of the spike, not the editor itself.