Tiptap Version 4.0.0 - Idea Hub

[bdbch]

Hey Community!

I am thinking more and more about what could be next for Tiptaps next major release and I wanted to discuss this with you. Below you will find some of my ideas that I'd love to discuss. Remind yourself that those ideas are just ideas, nothing is really decided on and we can always change things up.

Before v4 I will probably work and finish of the Decorations and Migrations API. So let's discuss until then what you guys want to see.

[bdbch]

Idea 1: Consolidate all Tiptap extensions, framework integrations and the ProseMirror wrapper into one package

Click here to read the whole idea

One very controversial idea I had was to move extensions into one big package that is tree-shakable. Basically having imports like:

• Core: import { Node, Mark } from '@tiptap/editor/core'
• ProseMirror: import { EditorState, Transaction } from '@tiptap/editor/pm/state'
• Kits: import { StarterKit } from '@tiptap/editor/kits/starter'
• Normal Extension: import { Placeholder } from '@tiptap/editor/extensions/placeholder'
• Node Extension: import { Blockquote } from '@tiptap/editor/nodes/blockquote'
• Mark Extension: import { Bold } from '@tiptap/editor/marks/bold'
• Framework Integration: import { Tiptap, useTiptap } from '@tiptap/editor/react'

Here are some pros and cons I see about this:

Pros

• Way easier to install and update: Instead of having 30 Tiptap dependencies, you'd end up with just one + maybe a few pro packages or third party deps.
• Faster setup: You'd always have everything ready to use and a Tiptap setup would be done faster.
• Optimized bundle size: Bundle size for modern bundlers should stay small as this code would be tree-shakable.
• Discoverability: Easier to discover new packages you may have not known about.
• Cleaner changelogs: Easier to upgrade / understand what changed in one Release instead of having a long changelog with just dependency bumps.
• Performance: Way faster CI/CD installs because the CI doesn't need to pull in 30 packages anymore.
• Developer experience: Documentation and onboarding will be easier.

Cons

• Larger local footprint: You would probably download a larger bundle into your node_modules directory, even though I don't think this should be a big problem as none of that size would end up on your app's bundle as long as you have a tree-shakable bundler.
• Bundler misconfiguration risk: If a user misconfigures his bundler or uses an old setup this could cause large bundle sizes again.
• Loss of granular versioning: You can't up- or downgrade individual packages anymore (even though this was never our idea to begin with, the current package versioning concept was meant that all @tiptap packages would be bumped together).
• Ecosystem disruption: This would break most third-party packages as they would need to update their internal imports to be compatible with Tiptap v4.

---

Overall I think it would be a nice idea, the only thing I bother about is:

• Bundle Size: I don't want to explode peoples apps with code they don't need.
• How do we manage dependencies? (lowlight for codeblocks, FloatingUI for menus, etc.) - though here I already thought about making them optional peer dependencies so users of these packages need to install those deps themselves.
• What about the ecosystem? I don't really like breaking everything pre 3 but at the same time people can stay on v3 until their package is updated or forked. It would be a shame if Tiptap itself could never move into any direction because of third-party packages.
• Framework integrations: Do we really want to add them all into the same @tiptap/editor package? or do we keep them in @tiptap/react, @tiptap/vue, @tiptap/svelte, etc. - I fear that some editors could trip up and somehow throw errors because it doesnt understand the concept.

Let's discuss this below.

[nmontavon]

8/10

yes, but do make sure that treeshaking works well. Yjs for example is large and still pulled in for non-collaborative editor instances or features.

As you release new versions almost every time anyways, nice change for less package manager noise.

[bdbch]

It's my main concern and it would mean we need to be very careful with how we import cross-module.

[sereneinserenade]

Love the idea, and it’d be great to have the same pattern for pro extensions too.

[nperez0111]

You know I'm very much for this idea (I tried to do it for V3, but settled for time).

I would even go as far as re-bundling prosemirror into the package instead of relying on it to be bumped with other deps, it will reduce the number of cross compat issues you may run into.

[bdbch]

Yep I also thought about moving the @tiptap/pm package into @tiptap/core itself (not sure if @tiptap/core is even the right name anymore since running Tiptap without ProseMirror seems to be hard anyway :D)

I'll experiment a bit around it, I'm mostly worried about accidential cross-imports & bundlers not really catching onto tree-shaking correctly. Would be a disaster if we blow up users apps.

[bdbch]

Idea 2: Move absolutely-required extensions into core

Click here to read the whole idea

This is somewhat related to idea 1. Right now, to get a working editor to run, users need to do the following things:

# with starter kit
npm install @tiptap/core @tiptap/starter-kit @tiptap/pm

# without
npm install @tiptap/core @tiptap/extension-document @tiptap/extension-text @tiptap/extension-paragraph @tiptap/pm

And then

import { Editor } from '@tiptap/core'
import { Document } from '@tiptap/extension-document'
import { Paragraph } from '@tiptap/extension-paragraph'
import { Text } from '@tiptap/extension-text'

const editor = new Editor({
  element: document.getElementById('editor'),
  extensions: [Document, Paragraph, Text]
})

I think I don't even have to explain what's the problem here. It's very verbose and just too much. Tiptap itself should already work out of the box with just one package. And since almost all packages require the core package anyway, we could just move everything there. This is also why I see this as related to the first idea as we move packages together.

In the Tiptap 4 way, we could then just do this:

# we would strip document, paragraph and text extensions from the starter-kit
# so they don't get registered twice if it is used
npm install @tiptap/core

and

import { Editor } from '@tiptap/core'

const editor = new Editor({ element: document.getElementById('editor') })

In my opinion, this is way cleaner and easier to understand. I'm not sure if we can somehow move the ProseMirror dependencies right into the core package and have the core package use them without any problems. That's something I'd need to experiment with.

One big question would be - how can I extend, configure or overwrite Document, Paragraph and Text then? For the rare cases this is necessary we could expose a new option on the editor.

Configure via object:

import { Editor } from '@tiptap/core'

const editor = new Editor({
  // we just confiugure the core extensions like this
  coreExtensions: {
    paragraph: {
      HTMLAttributes: {
        class: 'my-paragraph',
      },
    },
  },
  extensions: [
    Bold,
    Italic,
  ],
})

Configure via Extension.configure:

import {
  Editor,
  ParagraphExtension,
} from '@tiptap/core'

const editor = new Editor({
  coreExtensions: {
    // pass in the new extension instance via configure here
    paragraph: ParagraphExtension.configure({
      HTMLAttributes: {
        class: 'my-paragraph',
      },
    }),
  },
  extensions: [
    Bold,
    Italic,
  ],
})

Extending a core extension

import {
  Editor,
  ParagraphExtension,
} from '@tiptap/core'

// extend just like you always used to
const CustomParagraph = ParagraphExtension.extend({
  addAttributes() {
    return {
      ...this.parent?.(),
      variant: {
        default: null,
        parseHTML: element => element.getAttribute('data-variant'),
        renderHTML: attributes => {
          if (!attributes.variant) {
            return {}
          }

          return {
            'data-variant': attributes.variant,
          }
        },
      },
    }
  },
})

const editor = new Editor({
  coreExtensions: {
    // pass in your extended extension here
    paragraph: CustomParagraph,
  },
  extensions: [
    Bold,
    Italic,
  ],
})

Replacing a core extension with another extension:

import {
  Editor,
  Node,
  ParagraphExtension,
} from '@tiptap/core'

// Your custom extension
const CustomDocument = Node.create({
  name: 'document',
  topNode: true,
  content: 'heading block+',
})

const editor = new Editor({
  coreExtensions: {
    // overwrite it here
    document: CustomDocument,
    // configure others like this
    paragraph: ParagraphExtension.configure({
      HTMLAttributes: {
        class: 'paragraph',
      },
    }),
  },
  extensions: [
    Heading,
    Bold,
  ],
})

[bdbch]

Yep - Document and Text is always required, otherwise ProseMirror throws an error. And Paragraph is the default content node - and I think almost all editors require one.

[scramel]

As long as said core extensions are still customizable (which they are in your proposal) I don't see why not. Makes for an easier installation with no downsides at all.

[nperez0111]

Eh, I would not make the extensions "configurable", I would just have them be available on the @tiptap/core package, like:

import { Editor } from '@tiptap/core';
import { Document, Paragraph, Text } from '@tiptap/core/extensions';

This would not make the "required" extensions any more special than others as well as allowing you to be able to export more under that namespace.

[bdbch]

That's also a solution. The idea I had was that users usually don't really touch them in most cases and almost every editor needs those packages anyway. What's the reasoning to put them into a sub-export here?

I could imagine something like this:

import { Editor } from '@tiptap/core';

// This automatically includes all three extensions by default
const editor = new Editor({ element: document.querySelector('#app') })

and

// calling it DocumentExtension to avoid confusion with the default Document type
import { Editor, DocumentExtension } from '@tiptap/core';

const CustomDocument = DocumentExtension.extend({
  // ... options
})

// Same as above but because we pass through a node with `name: 'doc'`
// the default DocumentExtension is not registered by the ExtensionManager
const editor = new Editor({ element: document.querySelector('#app'), extensions: [CustomDocument] })

[nperez0111]

Two reasons for a sub-export, tree-shaking for those who don't need it (i.e. defining your own doc node separately from Node.create), and also for normalizing where to pull extensions and nodes from:

// core editor stuff
import { Editor } from '@tiptap/core';
// optional extensions you can compose for your editor
import { Document, Paragraph, Text } from '@tiptap/core/extensions';

I would value consistency of the API over the convenience, Tiptap is powerful because it doesn't prescribe all these defaults.

But, just an opinion

[bdbch]

Idea 3: Deprecate @tiptap/vue-2 and rename @tiptap/vue-3 to @tiptap/vue

Click here to read the whole idea

With the upcoming changes, I want to propose a major cleanup for our Vue integrations. Right now, having split packages for different framework versions is confusing, hard to maintain, and does not align with how we handle other framework integrations like @tiptap/react.

Specifically, I propose to completely deprecate @tiptap/vue-2 and rename @tiptap/vue-3 to @tiptap/vue.

Here are the main reasons why:

• Vue 2 is long past EOL: Vue 2 officially reached its End of Life (EOL) over 3 years ago (December 2023). Continuing to maintain, test, and support a package for an outdated framework version takes up valuable time that could be spent elsewhere.
• Cleaner and predictable naming: The current version-suffixed names (vue-2 and vue-3) are clunky and confusing for newcomers. Renaming the current Vue 3 package to just @tiptap/vue makes the ecosystem consistent and brings it perfectly in line with @tiptap/react.
• Unlocking future improvements: Maintaining backward compatibility with Vue 2 setups heavily limits our ability to leverage modern tooling and reactive patterns. Dropping Vue 2 lets us aggressively move the modern Vue package forward with cleaner code and better performance.

How this would look in v4:

# Old setup (Vue 3)
npm install @tiptap/vue-3

# New setup (Vue 3 / Future Vue versions)
npm install @tiptap/vue

Users who still absolutely require Vue 2 support would simply remain on Tiptap v3 packages, which will remain functional and accessible on npm.

Let's discuss below.

</details>

[nmontavon]

10/10

Let's get things moving along.

[rain-knows]

get it

[scramel]

Very much agree

[nmontavon]

Idea 4: First-class Svelte 5 support

Click here to read the whole idea

With Svelte 5 continuing to grow, it could be interesting to explore first-class support for it in Tiptap.

Since Svelte works very well with vanilla JavaScript libraries, Tiptap is already a pretty natural fit. A dedicated package could focus mostly on improving DX and integrating more cleanly with Svelte-specific patterns rather than wrapping everything in framework abstractions.

One particularly interesting area is Svelte 5 Attachments. Tiptap could potentially expose attachment factories that make editor setup extremely concise while also leveraging Svelte’s lifecycle and reactivity system efficiently.

There are also opportunities around modern Svelte features like effects, remote functions, streaming, and better client/server state handling for collaborative or AI-driven editors.

At the same time, there are some obvious tradeoffs:

• Tiptap already works well with vanilla JS, so a dedicated package may not be strictly necessary.
• It adds another framework integration to maintain long term.
• Svelte adoption is growing, but still smaller compared to React or Vue.
• Community packages like svelte-tiptap already exist, although some are not fully optimized for Svelte 5 or actively maintained.

Feels like the main question is whether there’s enough value in a first-party integration beyond what vanilla Tiptap already provides.

Let's discuss below:

[bdbch]

I'll look into it! :)

[bdbch]

I looked into it and I think we can ship this before 4.0!

[nmontavon]

cool! Let me know if you need any assistance, we can rally up the svelte troops.

[bdbch]

I have a branch open - if you want to you could check it out locally and test it yourself.
https://github.com/ueberdosis/tiptap/tree/feature/svelte-integration

[bdbch]

Svelte PR is open:
#7859

Let's see when it can land in a minor release.

[BoussonKarel]

Idea 5: Support rendering Tiptap inside an iframe

Click here to read the whole idea

One interesting direction could be better support for rendering Tiptap inside an iframe.

The main benefit would be proper isolation between the editor and the host application. App styles would no longer accidentally leak into editor content, and editor styles would stay fully contained as well.

It could also help with JavaScript isolation and make embedding editors into larger or more complex applications feel more predictable.

There are also some existing integration issues around iframe support today. For example, plugins sometimes use the global document instead of the iframe’s document. Mouse event listeners attached to the parent document also do not receive movement events happening inside the iframe for security reasons, which can break certain editor interactions.

I already opened a discussion about this earlier here: #7419

Let's discuss below:

[bdbch]

What problems are you running into with Tiptap and Iframes? Out demos in our docs are all iframe-rendered so I wonder if there is a special case we may miss there.

[BoussonKarel]

Plugins using document instead of the iframes document. Mouse event listeners on document don't receive info about mouse movement inside the iframe document, for security reasons, so plugins should use the right document of the iframe

I already have opened a discussion about it here earlier: #7419

[bdbch]

Great, thanks. I'll create an issue out of your other discussion.

[ashvinpraveen]

Idea 6: Explore Tiptap for React Native

Click here to read the whole idea

This is probably a long shot, but it could be worth exploring whether Tiptap can support React Native in some form.

Mobile apps are becoming more interesting again, especially with AI products. A lot of writing, editing, reviewing, and collaboration workflows are moving beyond desktop web apps.

Since Tiptap and ProseMirror are built around the DOM, proper React Native support would not be trivial. But even a limited approach could be useful, for example through better WebView support, shared schemas, or guidance for teams that want to use Tiptap in mobile apps.

The main question is what level of React Native support would actually make sense.

Let's discuss below:

[bdbch]

I thought about this a lot already. It's tough because Prosemirror is primarily bound to the DOM. I've read an idea where a hidden browserview could be used to hook into an editor state for input and state handling but it sounds very hacky.

I'd love to provide official React Native support but even then - it would be hard to map extensions to Native elements somehow, not only that but also plugins that rely on the DOM to exist.

[tugkanpilka]

This would be a game changer for me. I've tried a lot of different ways to implement TipTap into my app with iframe etc but at the end it doesn’t work very well.

TipTap is a great tool but lack of support for React Native is a big problem (for me).

[bdbch]

Idea 7: Make unique-id the default and give every node a stable identifier

Click here to read the whole idea

Right now, the UniqueID extension is an optional package that adds logic on top of transactions to assign IDs to nodes.

For V4, I think we should consider making stable node IDs a core behavior in Tiptap. That would mean nodes get an ID attribute by default, for example data-tiptap-id, data-node-id, or something similarly namespaced.

The main idea is simple: if we can always assume that nodes have stable identifiers, we unlock a lot of useful patterns across the editor.

For example, we could build utilities to:

• create selections from node IDs
• find nodes by ID
• resolve the current position of a node by ID
• map a node ID to the related DOM element
• find related internals like the NodeView, ViewDesc, or other editor-level structures
• sync individual nodes more reliably with external systems or databases

This could also give us better primitives for anchoring things inside the document.

Right now, for features like comments, suggestions, annotations, or similar document-linked metadata, we often have to rely on marks, positions, decorations, or custom mapping logic. That works, but it can get fragile and complex.

With stable node IDs, we could start thinking about anchors as a combination of:

• a stable node ID
• an offset inside that node
• transaction mapping to keep that anchor valid over time

That feels like a more explicit and scalable model than only relying on positions or marks, especially for collaborative and structured document use cases.

For end users, this could open up new core APIs around finding, selecting, syncing, tracking, and interacting with document nodes. Instead of every project solving this in a slightly different way, Tiptap could provide a shared foundation.

Of course, there are tradeoffs.

Adding IDs to every node means the document gets larger. Every node would carry some extra bytes, and depending on document size and ID format, that could matter. We would need to be careful about the attribute name, the ID format, and whether IDs are included in every serialization format by default.

There is also the question of whether this should be required behavior or just enabled by default. I think a good compromise could be making it opt-out, so users who really do not want stable node IDs can disable it and keep Tiptap closer to how it works today.

My current take: this makes sense as a default for V4. Stable node identity feels like one of those primitives that would make many advanced features easier, cleaner, and more consistent.

My questions:

• Does this make sense as a default behavior for Tiptap V4?
• Which attribute should we use? I would prefer a namespaced attribute to avoid conflicts with user-defined attributes.
• How much would this increase document size in real-world documents?
• Should IDs exist on all nodes, or only on certain node types?
• Should this be fully opt-out, configurable per node type, or both?
• Should these IDs be part of the persisted document by default, or only exist at runtime unless explicitly serialized?

Let's discuss below:

[tugkanpilka]

Last year when I was working on the Tiptap for first time, that was a big challenge for me. I didn't understand why node IDs are not supported in the first place, and it took me a while to figure out there is a separate plugin for that. I think it should be enabled by default.