Nova Tiptap Laravel Package

Product Decisions This Supports

• Editorial UX upgrade inside Laravel Nova. Swapping Nova's default textarea/Trix field for a Tiptap-based WYSIWYG gives content authors, marketers, and support staff real formatting — headings, lists, links, code blocks — without developer involvement. The measurable product win is fewer "please fix the formatting" tickets and faster content turnaround on the resources that matter (Pages, Posts, help-center articles).
• "Stay in Nova" vs. "stand up a separate CMS." For small-to-mid content surfaces, a drop-in rich-text field is often the deciding factor in whether a dedicated CMS is justified. It makes the cheaper roadmap answer — keep content in Nova, defer Statamic/Contentful/Sanity — defensible. Make that call explicitly rather than letting the field choice quietly make it for you.
• Build vs. buy vs. fork — the actual decision. Feature selection here is trivial; ownership model is the real fork in the road. At 172 stars, zero dependents, an archived repo, and a last release of 2024-06-27, the honest framing is "fork-and-own," not "install-and-forget." Budget it as a line item, not a footnote.
• Consolidating legacy WYSIWYG. For teams running CKEditor/TinyMCE in older Nova apps, this is a candidate to standardize editing UX across resources — provided the storage-format and rendering story is settled before rollout, not after.
• Acceptance criteria for the roadmap. The field persists a ProseMirror JSON document, not plain HTML. "Done" must therefore include: server-side sanitization, a shared JSON→HTML rendering path for preview and production, index/detail display rules that never expose raw JSON, per-field toolbar configuration, and round-trip fixtures for representative documents.
• A deliberate negative prioritization signal. The health score (1.64) and archived status are a de-risking prompt: timebox a spike before committing sprint capacity, and keep editor functionality off the critical path of a customer-facing launch unless a named owner exists.
• Forced upgrade planning. Adoption bakes "what happens at the next Nova major?" into the roadmap now, instead of discovering it as an outage later.

When to Consider This Package

Consider it only when all of the following hold:

• Your Nova major is one this package actually supports. Verify the Composer constraint against your Nova version first — version mismatch is the single biggest failure mode for Nova fields and the most common place a sprint gets wasted.
• You genuinely need rich text, not Markdown. If plain text or Markdown is acceptable, skip it; you'd be taking on fork ownership to solve a non-problem.
• You have in-house Laravel/Vue capability and will fork. Archived means no upstream fixes, no security response, no compatibility guarantee. If nobody owns the fork, don't adopt.
• The editor surface is internal or low-blast-radius — back-office authoring, not a regulated publishing pipeline or a high-traffic public front door.
• The storage format fits your pipeline. Confirm how ProseMirror JSON becomes HTML for your renderer, search index, email templates, API responses, and mobile clients before editors touch it. Resolve HTML-vs-JSON empirically in a spike rather than trusting the README.
• You can own server-side sanitization. XSS protection cannot be a client-side concern, and this package will not provide it.

Look elsewhere when:

• You need vendor support, an SLA, or a maintained release cadence — there is none.
• You are on, or planning, a Nova major upgrade; archived fields routinely break there.
• You need accessibility conformance, RTL/i18n, or collaborative editing guarantees — you will be building those yourself.
• Your content pipeline is regulated or high-traffic and can't absorb permanent fork maintenance.
• The team has no Vue/ProseMirror experience; debugging a headless editor wrapper without it is an expensive detour.
• A maintained Nova field alternative exists, or a small custom Vue field would cover the need — both are cheaper than indefinite fork ownership.

How to Pitch It (Stakeholders)

For executives. This is a small MIT-licensed add-on that gives our Nova admin panel a modern rich-text editor, so content and ops teams can write and format articles without developer help. The upside is a visibly better editorial workflow at essentially zero license cost, and it can defer a separate CMS purchase for small content surfaces. The caveat is material: the project is archived, has zero dependent packages, and its last release predates our current maintenance window. So the recommendation is not "adopt as a dependency" — it's "adopt as a fork we own." That means a small, bounded engineering investment up front (roughly a day to fork, spike, and document, plus recurring patch upkeep at Nova upgrades) instead of a recurring vendor fee. The decision we're asking for: approve that ownership model, or direct us to evaluate maintained alternatives first. Total cost is low; the risk is unmanaged abandonment, and we're proposing to manage it explicitly with a documented fallback.

For engineering. It's a thin Vue wrapper exposing Tiptap as a Nova field — headless editor, configurable toolbar via field meta, standard Nova conventions (component(), resolve, fill), publishable assets. Since it's archived with no dependents and no upstream, treat it as source, not a package: fork it into our org, pin an exact tag, add it to the Nova upgrade checklist, and document the fallback (a native Nova field plus a small custom Vue component). Validate the full compatibility matrix — Laravel, PHP, Nova major, Vue, bundled Tiptap — in a non-production spike on day one, and confirm the stored ProseMirror JSON matches our renderer before any editor goes near real content. Non-negotiables before rollout: server-side HTML sanitization, JSON→HTML rendering parity tests, content round-trip and XSS regression tests, and index/detail display rules that never leak raw JSON. If our Nova version isn't already supported, that's the stop sign — don't sink time into porting an unmaintained field.