Laravel Nova Tiptap Field Laravel Package

Technical Evaluation

Architecture fit. wamesk/laravel-nova-tiptap-field is a drop-in Nova form field that wraps Tiptap (a ProseMirror-based headless editor) in a Vue component and persists rich text through the standard Nova field contract. It does not touch domain code: a TPM can treat it as an authoring-layer dependency, declared per-resource, with no changes to models beyond the content column itself. Fit is strong if the team already standardises on Nova for admin authoring; it is a poor fit if authoring must be exposed outside Nova (customer-facing editors, headless CMS workflows) or if the front end is not Laravel/Blade.

Integration feasibility. Low-to-moderate. Requirements are the usual Nova field mechanics — a FieldServiceProvider, published/compiled JS assets, and a working npm/Vite build in the host app. The real planning question is not "can we install it" but "which versions are we pinning": Nova major (4 vs 5) and the bundled Tiptap major must be validated together, and this package's 2.x line is very young. Budget a short spike (1–2 days) to confirm the editor mounts correctly in form, detail, and index contexts before committing.

Technical risk. This is where a TPM should spend the most attention:

• Maturity: 2 stars, single maintainer, 2.0.1 released as a one-line patch fixing "Showing editor." That is a rendering regression fix, which tells you 2.0.0 shipped with at least one display-context defect. Expect patch churn through 2.0.x.
• Score 0.31 corroborates low ecosystem adoption — there is little community signal to fall back on if the maintainer pauses.
• XSS surface: rich text produces HTML. The storage format (sanitised HTML vs ProseMirror JSON) and the sanitisation policy are host-app responsibilities unless the README proves otherwise; the client-side editor is not a security boundary.
• Version coupling: Tiptap major bumps break extensions; a Nova 4→5 upgrade will likely force a lockstep package upgrade with no migration tooling.
• Bus factor: no visible multi-maintainer governance, security policy, or response SLA.

Key questions to resolve before approval.

1. Does 2.0.x officially support our Nova major, and which Tiptap major is bundled?
2. What is the persisted format — HTML string, JSON document, or configurable — and is there documented migration from 1.x?
3. Is output sanitised anywhere in the render path, or entirely on us?
4. Precisely what did "Showing editor" fix, and is it verified across create/update/detail?
5. Does the field expose extension registration hooks and toolbar config, or will customisation mean forking resources/js/field.js?
6. Does it support our required validation, max-length, and readonly/disabled states?
7. What is the maintainer's release cadence and issue-response history?

Integration Approach

Stack fit. Assumes Laravel + Nova (Vue 3) + a Node build pipeline. The decision that constrains everything downstream is the storage format: sanitised HTML (trivial to render, searchable with LIKE, works with existing Blade) versus ProseMirror JSON (lossless re-editing, but requires a renderer and kills LIKE search). Pick one per column and document it; do not mix. If full-text search matters, plan a derived plain-text excerpt column populated on save.

Migration path. Treat this as greenfield for new content types first. For existing rich-text columns (Trix, Markdown, raw HTML), plan a one-way transform into the chosen format and keep the legacy field available as a fallback until the transform is validated on real content. Because the 1.x→2.x history is undocumented, do not point this field at a column where content loss is unrecoverable without a backup and a dry run — Tiptap re-serialises on open and will silently drop schema-invalid markup the first time an editor saves a legacy record.

Compatibility. Pin the package (^2.0.1), Nova, and Tiptap versions explicitly in composer.json / package.json and commit the lockfiles. Add a smoke test that asserts the editor mounts in create, update, and detail views — that is exactly the surface 2.0.1 touched and the fastest regression detector we can own.

Sequencing (suggested delivery plan).

1. Spike (1–2 days, one dev): install 2.0.1 against current Nova, confirm mount in all three contexts, confirm sanitisation responsibility.
2. Decision gate: storage format + sanitisation policy documented and signed off by whoever owns the public render path.
3. Pilot: one low-risk resource, legacy field kept as fallback.
4. Validation: round-trip test (create → save → reload → render) plus API/consumer check.
5. Rollout: remaining resources.
6. Retirement: legacy rich-text fields removed only after the pilot has run a full release cycle.

Operational Impact

Maintenance. Ongoing cost is real but bounded. Budget one composer update / npm update cycle plus a re-run of the mount smoke test after every Nova or Tiptap bump, and one package-upgrade project per Nova major. Because the package is single-maintainer, assume we may eventually need to fork it: keep customisations in our own component overrides rather than patches in vendor/, and note that the extension-hook question (Key Question 5) determines whether a fork becomes mandatory the first time Product asks for a custom node.

Support. Upstream support is best-effort via GitHub issues with no SLA. Placing this on a critical authoring path requires a named internal owner who can read the Vue component and the ProseMirror schema — designate that person before adoption, not after the first incident. For high-value authoring flows, keep a contingency in the plan: either a commercial Tiptap-backed editor or a first-party Nova field.

Scaling. Rendering is client-side and cheap; the cost is editor JS bundle weight on Nova pages, mitigated by declaring the field only on resources that need it. Server-side cost is storage — a JSON document is materially larger than plain text, so watch column sizing and any search indexing built directly on the column. Derive and index an excerpt instead.

Failure modes and detection hooks. Each needs an owner and a check:

• Editor fails to mount after a Nova/Tiptap upgrade — highest likelihood, evidenced by 2.0.1. Hook: mount smoke test in CI-adjacent QA.
• Content normalised or lost on first open of legacy records — hook: backfill dry run on a production copy before cutover.
• Unsafe HTML rendered unescaped on the public site — highest severity. Hook: server-side sanitisation on save in a model observer, plus a CSP, regardless of what the field does.
• Silent payload shape drift between create and update — hook: round-trip feature test asserting the persisted value.
• Storage-format change leaving the front end unable to parse — hook: a one-off backfill command, run deliberately, never silently coerced on read.

Ramp-up. A Laravel developer familiar with Nova is productive on basic field usage within a day. Custom Tiptap extensions, toolbar changes, or a storage-format migration require ProseMirror familiarity — plan roughly a week for whoever owns that work. Net TPM recommendation: approve for pilot use on non-critical authoring surfaces with pinned versions, a documented sanitisation policy, and a named owner; defer any decision that depends on custom extensions until the extension-hook question is answered in the spike.