Tiptap V3 Roadmap

[nperez0111]

Hello, Tiptap community!

Internally, we are planning out next steps for the next major version of Tiptap v3. We thought that it would be great to involve the community in this planning!

There are some items which we've already decided and made some progress on, while others are only in the ideation phase or need some feedback. I will be posting each feature/idea in a separate thread, so that we can keep the discussion tight to a specific feature as well as to allow voting on particular issues.

So, please upvote an idea if you think that it will be a valuable addition to Tiptap!

---

We've already started to make some progress towards v3 on the next branch if you want to check out some of the upcoming changes like:

• Replace the tippy package with floating-ui: Remove tippy.js and replace with Floating UI #5398

  • We’ve had a number of issues with tippy come up: element removal errors, an awkward API and strange integration into apps. But, no more, we are moving to using @floating-ui/dom which is tippy’s official successor and offers a much more convenient API

• renderHTML JSX: feat(jsx): add @tiptap/jsx for more convenient rendering of Tiptap content #5558

  • With the new JSX functionality, we can now support JSX as the return type from renderHTML resulting in this nice API:

    Node.create({
       renderHTML({ HTMLAttributes }) {
        return <div {...HTMLAttributes}><slot /></div>;
      },
    })

• Optimal Framework Performance by default

  • Tiptap 2.5 significantly improved the performance of the framework integrations, but the React integration was an opt-in change to not break users, no more. The React integration will be modified to have the more performant shouldRerenderOnTransaction API be default false, with an opt-in to the previous in-optimal behavior.

• Static Renderer: feat(static-renderer): add @tiptap/static-renderer to enable static rendering of content #5528

  • This allows rendering of Tiptap content outside of an editor instance, it supports multiple targets, HTML strings, React elements and is flexible enough to render to much more.

• Support for Prosemirror Markviews: feat(core): add support for markviews #5759

  • Prosemirror Markviews allow for flexible rendering of a mark & it’s inner content. Allowing you to attach event handlers to the element for more dynamic mark experiences.

Please vote & discuss your favorites below!

Or, add your own if you've been looking for something yourself!

[nperez0111]

Package versioning strategy (Status: Feedback)

Tiptap major version 2 had all packages bumped at the same time, this was to try to make it clear what versions were compatible with one another, but we are thinking about decoupling versions. We may be moving towards a model where if a change is made to only one package, only that one package has it's version bumped, this should help make it clear what actually changed between versions (rather than getting a package bump because any tiptap package was bumped).

This would mean that packages would be bumped a lot less often (since core is 80% of our changes).

TLDR; Moving from:

@tiptap/[email protected]
@tiptap/[email protected]
@tipatp/[email protected]

To:

@tiptap/[email protected]
@tiptap/[email protected]
@tipatp/[email protected]

[robertmoura]

I don't really mind either way. I slightly prefer the suggested change but It's more of a subjective choice. I've always just thought it was a bit unwelcome to get a list of updates from Tiptap. Usually looks like this for me when I use yarn upgrade-interactive:

[chrisdeeming]

Much prefer the current approach. We've recently moved to something similar with our own software.

[StephanMeijer]

In favor of strictly adhering to SemVer. Having a version 2.9.1 that could have identical code 2.8.1 or 2.5.3 is a tad weird and not fully conforming to semantic versioning.

[bcorcoran]

What is the point of maintaining separate packages if they'll all get bumped to the same version anyway? They might as well move to a monorepo.

[Nantris]

I am strongly in favor of the current approach. You know everything is on the versions that are meant to be compatible with each-other without any extra effort.

[nperez0111]

Package grouping (Status: Feedback) #5469

We are trying to reduce the number of overall packages we have.

Right now, to have a table in your application you need to depend on @tiptap/extension-table @tiptap/extension-table-cell @tiptap/extension-table-row @tiptap/extension-table-header which, is just too many packages for what a user actually needs (who would need a table but not table cells?).

So, we are going to maintain the existing packages to not break existing apps, but have them all be re-exports on a single package @tiptap/extension-table.

Relatedly, we also want to introduce smaller kits of functionality like for tables, lists, and text styling (bold, italics, underlining, etc.).

[rfgamaral]

Sounds good. I never used the table extensions, but the issue seems similar to extension-list-item. This package alone serves no purpose, so it makes sense to group related packages that need one another to fully function.

[nperez0111]

Drop UMD support (Status: Decided) #5455

We’ve moved build systems for a much faster development experience, unfortunately, this means that we will be forced to drop UMD builds of our packages since it is not supported by our build tool (tsup). UMD is a very old format so this should not be a concern for most consumers

[nperez0111]

Starter-Kit (Status: Decided) #5466

We want to make it easier to manage multiple sets of extensions, and give a better out of the box experience with Tiptap. Historically, we had the @tiptap/starter-kit package which made it easy to get started with your editor, but, we want to add even more functionality into the main starter-kit. Like, links, underlining and the list keymap extension.

[nperez0111]

Package manager (Status: Decided but not implemented)

NPM used to be a good package manager, but it has been left behind in terms of speed and functionality, we will migrate off of it internally, but this should have no effect on package consumers. Currently we are deciding between pnpm & bun, with a slight preference towards pnpm for it's ability to publish packages

[Mansehej]

+1 for pnpm

[eshimischi]

+1 for bun

[chrisdeeming]

Another +1 for pnpm. My local dev environment for Tiptap now uses pnpm.

[bcorcoran]

+1 pnpm

[gethari]

+1 pnpm

[nperez0111]

Decorations API (Status: Decided) WIP: #5437

Tiptap users have drop down into Prosemirror plugins, whenever they wanted to leverage Prosemirror decorations, now we are experimenting with an API that will make Decorations easy. Feel free to comment on our PR here: #5437

We aren't entirely sure at the moment what this API will look like, but in Tiptap fashion we hope that it is flexible enough to handle all of your decoration needs!

[rfgamaral]

This is only meant for decorations, right? In other words, we'll still need to drop down into ProseMirror plugins for more complex things, right?

[nperez0111]

Markdown extension (Status: Idea)

We’ve heard you, we want to build a solution to have the editor both accept & output content as markdown, in the age of LLMs which are quite good at outputting markdown, it is a must! Of course, this will be a tradeoff since markdown is an ill-defined format, but we understand the need for it.

Our idea is to offer a first-party extension which will add support for inputting & outputting markdown. To keep bundle sizes lean, we would not want to force this on users who do not need such an extension. We are still working on the details of what this would mean so please leave your ideas below!

[rfgamaral]

How do you intend to make this work with custom extensions for things that Markdown have no support for? For instance, mentions? Will you provide means for consumers to define the output Markdown for each extension, especially custom ones? How about pasting a full Markdown document, did you consider that? You'd need every single extension to provide an input/paste rule, and some of them currently don't (i.e. links). These are all things that we had to figure out in Typist (which has Markdown support).

From my experience on adding Markdown support to Typist, this will be quite the endeavour to get done right, in a way that works for everyone, and is customizable (some people might have strict requirements in the Markdown output, I know we do). Regardless, built-in support sounds amazing if done right. For instance, some ideas:

• Every extension should have input and paste rules to handle Markdown
• Every extension will probably need a renderMarkdown and parseMarkdown methods
  • Defaults can be provided, but users should be allowed to customize
• It should be possible to tweak/extend Markdown support for custom requirements

This is just from the top of my head.

---

Although I see this as a great idea, and something that a lot of people would love to have, I'm also thinking of the amount of work involved to get it done right (unless you forgo customizability). And in that sense, I wonder if your efforts aren't best applied to make the core Tiptap editor better in all fronts.

[nperez0111]

@rfgamaral Exactly the sort of pushback I wanted to see.

You are right on all fronts, and you are right to point out that this is a big challenge to overcome.

From my current understanding here is how I'd approach this:

• You are right, "Every extension should have input and paste rules to handle Markdown", doable and nice to have in any case
• Extensions should be able to define renderMarkdown with a fallback to plain html (from the already required renderHTML)
• I would not have parseMarkdown be the responsibility of each extension, since that would require shipping a markdown parser for everyone that uses that extension, and you'd have the possibility of multiple extensions matching markdown content. I'd instead leave markdown parsing and mapping to be the responsibility of a new separate markdown extension
• Tweaking output markdown should just be Node.extend({ renderMarkdown: (node)=> `>${node.children}` }), Tweaking the parsing of markdown will depend on how we do that mapping.

To ease your concern around the amount of work to do this, it definitely would be a lower priority project.

[rfgamaral]

Looking forward to seeing how this evolves. Also, since I've spent quite some time around adding Markdown support to Tiptap/Typist, feel free to tag me in future public discussions about this topic. I'm happy to brainstorm with you folks.

[StephanMeijer]

Inspiration can be drawn from ProseMirror.

[nperez0111]

Better TypeScript typings (Status: continuous improvement)

To improve the typing of the project overall, we need to completely refactor the typings we have right now, this would allow typing of things like attributes, HTMLAttributes, the editor storage API and so on…

Doing this in a major version is a natural place to make this sort of a change as it may affect how you type your projects. Give your ideas of what you would like to be better typed below!

[rfgamaral]

Doing this in a major version is a natural place to make this sort of a change as it may affect how you type your projects.

I'm stressing out just thinking about this 😅

Last time the typings changed for things like these, it was a pain to fix them on our side. But I guess this is part of the job, I'm in no way suggestion to keep the TypeScript typings as-is. If they can be better, let's make them better 💪

[nperez0111]

Totally get that, the hard part is that people want the typings to be better but we also have to maintain compatibility with previous versions which is very difficult to juggle.

It doesn't help that we've littered peoples code with things like:

declare module '@tiptap/core' {
  interface Commands<ReturnType> {
    bold: {
      /**
       * Set a bold mark
       */
      setBold: () => ReturnType,
      /**
       * Toggle a bold mark
       */
      toggleBold: () => ReturnType,
      /**
       * Unset a bold mark
       */
      unsetBold: () => ReturnType,
    }
  }
}

Hopefully, we can define the types in such a way that they are backward compatible, but if not, we should at least offer a codemod or at least an easy to use guide.

[StephanMeijer]

Oh yes! Please! I want this yesterday. I think all the locations where there is being typed with any should have highest prio. Our own code is less type-safe due to Tiptap being not that strict with types.

[nperez0111]

Trailing Node Extension (Status: Decided)

This extension automatically adds an additional empty node at the end of your document to allow the user to easily continue writing content. This resolves an issue, where if a table is the last node within your document it can be tricky to get the selection after it.

This extension has been in our Tiptap "experiments" for several years now, we want to upgrade it to be a fully-fledged extension we will support and maintain. See it's demo here: https://embed.tiptap.dev/preview/experiments/trailingnode/

[rfgamaral]

I find it weird that this is an extension, why isn't built-in core behaviour? Also, am I only hearing about this extension now? 😅

where if a table is the last node within your document it can be tricky to get the selection after it.

What other scenarios, besides tables, could this extension fix? I'm asking because although I haven't really felt the need for such extension, maybe that's because I know how the editor works, and I can always work around small issues like these, but our users probably can't (which could generate more support tickets). So I'm wondering what other nodes could this help with?

[nperez0111]

It isn't core behavior because we want the editor core lean and predictable. This would be installed to the editor and is based on this experiment: https://embed.tiptap.dev/preview/experiments/trailingnode/

This is more of a workaround than anything, but it would also help with things like an image just being pasted in as the last piece of content and now the user cannot just focus past it to continue writing.

For example, in this demo, you can't just click after this image to keep writing, you have to get your cursor into the editor then arrow toward the end just to type after it: https://tiptap.dev/docs/examples/basics/images

[svenadlung]

I think this could be part of Tiptaps StarterKit, as it is the default in most editors and people are used to it.

[rfgamaral]

For example, in this demo, you can't just click after this image to keep writing, you have to get your cursor into the editor then arrow toward the end just to type after it: https://tiptap.dev/docs/examples/basics/images

I think I've been working around with the gapcursor extension, but this feels like a better approach. How stable is this experiment? I might introduce it in our editor. If I do, do you think the gapcursor extension is still required?

[svenadlung]

Definitely still necessary. E.g. between 2 images. The new extension is only for the last node in the document. I have an updated version of the experiment. I can create a PR for it soon.

+ it behaves a bit different. It adds the default node (paragraph) to the end of the doc instead having a virtual "cursor".

[nperez0111]

SuggestionMenu Extension (Status: Idea)

Implementing something like a slash-command is very difficult to do, and even more difficult if you use a framework like React or Vue to render the UI within the menu. We want to make it easy with a first-class component for each of the frameworks like we provide with BubbleMenu & FloatingMenu.

[Chaddeus]

Definitely. I've sort of built my own /command implementation, but a "native" one would be ideal.

[rfgamaral]

Implementing something like a slash-command is very difficult to do

Maybe I'm not seeing the whole picture, but what's so difficult about it compared to the mention extension, or even the bubble and floating menus? What am I missing?

[nperez0111]

The bubble menu and floating menu are easy because they have React and Vue bindings.

Mention & Suggestion would be improved in a similar way. Instead of having to manage the popover state & and mounting/unmounting the React or Vue components yourself, you'd just use a React component and render your UI.

[rfgamaral]

I see, thanks for clarifying.

[mattkrick]

radix-ui (or radix-view for vue) has been a joy to work with wrt a11y, focus management, managing portal children (i.e. hitting escape only closes the top-most portal). I've been using that wherever I can. I see you've used in the block-editor example too!

I wouldn't be mad if tiptap took a strong opinion & made it a dependency. With a refactored render() function in the suggestion util you could even get rid of tippy/floating-ui in favor of a more expressive API.

[nperez0111]

Indentation Extension (Status: Idea)

We’ve heard your feedback, it is strange that you hit tab and the content does not just indent properly. This would be an extension that allows you to indent content as you'd expect.

For example, with Google Docs you can indent a paragraph node several levels:

[rfgamaral]

What do you mean "indent content"? What type of content? Bullet and ordered lists? Shouldn't this be fixed on the extension-list-* extensions? I'm confused by this one.

[nperez0111]

People want to ability to indent and outdent arbitrary content, like you'd see in Word or Google Docs

So it is more than just list items, although we have gotten feedback as well where people want to be able to indent those even more than they can right now (e.g. 1 level more than what the nesting allows).

[rfgamaral]

Oh, I see, thanks.

[StephanMeijer]

Please note this could have interesting effects relating to the Conversion API, not sure how Pandoc handles converting indents.

[nperez0111]

Content Migrations (Status: Idea)

This would introduce the ability to re-write Tiptap JSON from a previous incompatible version, to the latest version your editor supports. This would allow gradual migration of content as it is edited by others.

Something like: https://github.com/remirror/prosemirror-migration may be interesting to look at.

[afomera]

YES please, please provide an upgrade path that doesn't require migrating content ourselves in one big go 🙏 it makes it hard to do so when you're storing millions of JSON blobs from rich content.

this has been a pain point for me, as well trying to figure out how to migrate/modify existing content once an extension is rolled out but then you need to make changes, so I like the idea of migrations like the example posted.

[WilliamIPark]

This would be a big one for us at Niice. It's thankfully something we've avoided needing for the most part, but not having it is pretty scary for us.

[StephanMeijer]

Big one, specifically also if we can migrate our custom nodes and attributes.

[dbousamra]

Is there any room for any more Ideas? In particular, I'd love to see page (i.e. automatically breaking, and ability to render as a page) somehow integrated. I know it's a super difficult problem, but for certain use cases it's crucial

[nperez0111]

Definitely room for more ideas. Pagination is a really difficult problem that we haven't yet found a solid approach for yet. We've seen a couple of solutions crop up, but they all are dependent on specific implementations which wouldn't fit with the rest of the project. Hopefully we do come upon one soon though!

Appreciate you adding to the conversation!

[jonahallibone]

@nperez0111 I'd also love to see this feature. It's certainly hard and I've honestly spent a fair bit or time trying to get some kind of support for this in myself. I want to underscore how import this feature is perceived to be though. Our customers bring up time and time again that our editor needs to have page breaks. Obviously this is our problem to solve, not yours, but I do really love using TipTap for this feature.

I did not pay much mind to feedback at first, but we've reached a critical mass of requests where I have to consider migrating to a tool which supports it for our main document editor (we'll still use TipTap for comments etc).

I guess the only point I am making is that a lot of users are accustomed to page breaks in rich text editors where everything else looks like MSWord or GDocs, and I wanted to share that my deference to this was ultimately overwhelmed by our customer feedback, and it would be really incredible for TipTap to have.

[lvzhenbo]

Hopefully there will be full support for mobile, where there are currently a few issues such as #4532

[nperez0111]

There is never such thing as "full support for mobile" there are a number of things both Tiptap and Prosemirror try to smooth out for mobile but the fact of the matter is that contenteditable is a mess of a spec with tons of browser specific quirks

[GreedyWhale]

Problems with non-English input and on the ios system, hopefully it can be fixed

[nperez0111]

Is there an issue for this already? @GreedyWhale

[aaron-kettl]

I'd like to submit an idea. I'm currently building an application with TipTap called Quikest AI.

I've been observing what LangChain is building for multi agent orchestration. They recently open sourced the Open Canvas demo, which replicates the ChatGPT 04-Canvas concept. What's powerful is the multi-turn chat to update document, and the specific agent actions to modify the style of the whole document.

Is there any way to add an action bar to a TipTap doc to rewrite a the whole document with AI to replicate this muti-agent action experience that you see in the ChatGPT Canvas experience? And even better, I would like to provide my own system instructions that are based on my application's use cases to customize the actions.

Thanks for all your hard work to make TipTap better for all of us!! 🙌

[nperez0111]

I think that what you are describing is more in-line with our paid offerings, like, the content AI extension: https://tiptap.dev/docs/content-ai/getting-started/overview

[kart-c]

I would like to submit an idea. Can the table extension have the add or delete row / column (Like in this template) Decoration by default? Or can this be packaged as an additional extension?

Initially I had a hard time implementing this with node views (was unaware of the template code), but then I took reference from the template ❤️ and was able to implement this.

[nperez0111]

That is a great idea @kart-c, I think it'd be valuable for people too. I do question how the API will work though, especially since tiptap will need to be framework agnostic, maybe just a mounting element factory or something 🤔

[kart-c]

I haven't really explored much about it, but maybe some sort of BubbleMenu where the user can provide their own menu inside it as required? Sort of like how anyone using the mention extension has to add their own suggestion menu for it to work.

[nperez0111]

Excalidraw as a node (Status: Idea)

Excalidraw is an embeddable virtual whiteboard, distributed as a React component. It'd be great to embed this within a Tiptap document a custom node to allow the user to draw up their ideas right within the text editor.

They represent their content as a large JSON blob, so using the Tiptap Cloud or stored directly in your editor, we can store this as being associated to your editor content.

[chrisdeeming]

There's not a lot here to dislike! Hugely support everything you guys are working towards. Thanks for sharing the roadmap @nperez0111

What is the current thinking/status of integrating Pro extensions to be core/open source extensions?

Pro extensions being privately published and closed source used to make a lot of sense. After all, Pro extensions could only be used by customers who were paying.

Now the Pro extensions are available to all customers, subject to creating an account (even a free account) so it no longer seems logical to treat Pro extensions differently.

Open sourcing them would reduce confusion and it would allow the wider customer base to contribute fixes and new functionality in the same way they might contribute to the current core extensions.

It would be somewhat reasonable to keep the concept of "Pro extensions" for things that do actually need a paid plan, such as collaboration and AI extensions.

I think the team have previously commented that this might be something you'd be looking to do in the future, and therefore I was surprised to not see it in this list. What is the current thinking surrounding the Pro extensions?

[nperez0111]

Now the Pro extensions are available to all customers, subject to creating an account (even a free account) so it no longer seems logical to treat Pro extensions differently.

The Tiptap Pro license only allows free usage by single developers, as well as other restrictions, so this is not technically true.

Open sourcing them would reduce confusion and it would allow the wider customer base to contribute fixes and new functionality in the same way they might contribute to the current core extensions.

We've thought about open sourcing a couple of them, but do not intend to open source all of them.

We have more thoughts on this, but it is dependent on some upcoming changes to our pricing model that we have not released publicly so I cannot speak to it here.

[Nantris]

I hadn't realized the Pro extensions were available for use for solo developers. I poked around looking for the other restrictions you mentioned but couldn't readily find them. Could you point me to a link or briefly outline them @nperez0111?

<3 TipTap

[nperez0111]

Pro extensions are all licensed under the Pro License: https://tiptap.dev/pro-license

I am not a lawyer, but it even has an examples section which should make it clear whether you are abiding by the license

[Nantris]

Thanks, and sorry! Not sure how I overlooked that link.

[rfgamaral]

I have one suggestion: Rewrite from scratch the Suggestion utility. The current one is hard to reason with, and has a few crucial bugs (there are issues around for these). The new one should be "bug free", and with all the features with the current one.

[nperez0111]

I agree with this whole heartedly, suggestions is definitely a bug bear right now

[einarpersson]

I just want to say that whatever you do, don't mess up Svelte compatibility! (from a happy user of https://github.com/sibiraj-s/svelte-tiptap)

[aoleksyshyn-spscommerce]

I'd love to see resizable images with possibility to align them (left, center, right, wrap image with content).

[timheerwagen]

The ability to display the image with a caption inside a figure would also be nice. The same behavior for videos.

[nperez0111]

Putting aligning aside, since I can see that being something semantic.

How do you implement something like this in a headless way? We don't have anything else like this.

[Nantris]

I think it would just be nice if images readily stored their dimensions as attributes to avoid content shifts even without resizability. This is already on our internal wishlist, so I figured I'd share it here.

[clemente-xyz]

Any chance for Feature Request: Pagination extension (A4 format content) guys? Is really needed and asked by the community!!!

[nperez0111]

Asked for here: #5793 (comment)