Tiptap Editor Bundle Laravel Package

Product Decisions This Supports

• Framework-fit triage — do this first. Despite the "Laravel package" framing, this is a Symfony bundle: a Symfony Form type, a Twig template, DI/config wiring, and a prebuilt Vite IIFE of Tiptap/ProseMirror. It does not drop into a Laravel app. The decision it actually informs is "which PHP stack is this for?" — if Laravel, treat it as a reference implementation to copy, not a dependency to install.
• WYSIWYG modernization roadmap. Replacing CKEditor/TinyMCE/legacy rich-text widgets in admin and CMS screens with a ProseMirror-based editor while keeping the exact same submit contract (HTML posted as a string in a textarea).
• Build vs. adopt scoping. The bundle packages glue work you'd otherwise hand-write: form type + widget/view options, Twig integration, configurable toolbar/extension set, and a compiled frontend asset. Adopt if that saves more than your spike cost; build if you'll customize beyond recognition anyway.
• Data-model decision. Because content round-trips as HTML through the underlying textarea, persistence stays TEXT/VARCHAR — no JSON-document column, no migration, reversible per field. That's both an architectural constraint and a de-risking argument for "HTML in a textarea" over "Tiptap JSON in JSONB".
• Licensing decision. Bundle is MIT; Tiptap core and ProseMirror are MIT. Removes the CKEditor 5-style "GPL or commercial license" question and the legal review attached to it.
• Use cases it serves. Back-office authoring: blog/CMS body fields, knowledge-base and policy pages, product copy, email-template bodies, internal announcements — any rich-text field edited by staff.
• Portfolio risk posture. 0 stars, 0 dependents, effectively one release: an unvalidated, single-maintainer component. The decision output is "spike candidate for non-critical surfaces," not "team standard." MIT plus a thin wrapper means a cheap exit if it stalls.
• Roadmap items it hands to you. If adopted, the backlog is yours, not the vendor's: image/media uploads, link/table/code-block extension set, HTML sanitization on render, toolbar localization, and accessibility review.

When to Consider This Package

Evaluate or adopt when all of these hold:

• Symfony 6/7/8, PHP >= 8.1, and the field lives inside a Symfony Form.
• A modern editor with a small dependency footprint is enough, and a plain-textarea storage contract is acceptable.
• Your team can own a Vite/pnpm build and a small public asset tree (the repo keeps a generated src/Resources/public/tiptap-editor.js).
• You're comfortable forking and patching under MIT — there is no community to fall back on.
• Surface risk is low: internal admin/editor tooling, not public-facing user-generated content.
• You'll do the diligence: read the source, check the tests, confirm the Tiptap extension set (headings, lists, links, images) matches the brief, and confirm HTML sanitization is handled elsewhere in your stack.

Look elsewhere when any of these hold:

• Laravel or non-Symfony PHP. No Laravel form-type, Blade, or Livewire binding exists; you'd integrate Tiptap directly and take on the same glue this bundle exists to remove.
• You need vendor support, an SLA, an active community, or a security-response commitment. Zero stars/dependents and a single release are disqualifying for regulated or customer-facing surfaces.
• You need collaboration, comments, track-changes, or real-time co-editing out of the box — those are Tiptap's commercial Cloud/Pro capabilities, not part of this wrapper.
• You need structured document storage (Tiptap JSON) or a headless/API-first editing flow.
• You need a hardened, WCAG-reviewed, fully localized toolbar out of the box — a minimal wrapper typically won't supply it.
• You have strict CSP or asset-pipeline constraints and can't ship a prebuilt IIFE plus inline init/config.
• You don't actually need WYSIWYG — Markdown with preview is cheaper to build and maintain.

Cheap way to decide: timebox a spike in one admin form and measure (a) integration hours, (b) how much extension/config customization was needed, (c) what a hand-rolled Tiptap + Symfony form type would have cost. Adopt only if (c) clearly exceeds (a) + (b).

How to Pitch It (Stakeholders)

One-liner for executives. A small, MIT-licensed add-on that gives our Symfony admin forms a modern rich-text editor in place of plain textareas, without changing how content is stored — low cost, low commitment, easy to reverse. The main risk is maturity (young, single-maintainer package), so we'd pilot it on internal screens only.

Why it matters (business). Editors get a modern experience — headings, lists, links, formatting — while storage stays exactly as it is today: no data migration, no schema change, no re-platforming. It also sidesteps CKEditor's GPL-or-paid licensing question entirely.

Engineering summary. It's a thin wrapper: a Symfony form type, a Twig template, DI/config wiring, and a prebuilt Vite bundle of Tiptap/ProseMirror. HTML round-trips through the underlying textarea, so server-side code is untouched. We'd own the frontend build and any editor extensions — and we should read the source before adopting: 0 stars, 0 dependents, one release.

What we're asking for. Approval for a timeboxed spike (1–3 days) in one internal admin form, with a go/no-go at the end. Success = it renders, saves, and reloads content in an existing form with zero persistence changes, and the effort is lower than building the equivalent Tiptap form field ourselves.

Caveat to state up front. This is a Symfony bundle. If the target product is Laravel, the recommendation flips to "copy the pattern, not the dependency," and the spike becomes a short Laravel/Livewire Tiptap integration instead.