Should we move all extensions to its own package?

[philippkuehn]

I thinking of moving all extensions from tiptap-extension to its own package. I think every implementation of a rich text editor is extremely individual so a user should only load needed extensions. I know there are features like tree-shaking but related to #16 it seems hard to configure for some users (me too 😅).

So instead of importing all extensions from tiptap-extensions

import  {
  BlockquoteNode,
  BulletListNode,
  HardBreakNode,
  HeadingNode,
} from 'tiptap-extensions'

we could import extensions like this

import BlockquoteNode from 'tiptap-bockquote-extension'
import BulletListNode from 'tiptap-bulletlist-extension'
import HardBreakNode from 'tiptap-hardbreak-extension'
import HeadingNode from 'tiptap-heading-extension'

Also scoped packages are becoming more and more popular. I'm not sure about its features/caveats but maybe it is something we could think about.

import BlockquoteNode from '@tiptap/bockquote-extension'
import BulletListNode from '@tiptap/bulletlist-extension'
import HardBreakNode from '@tiptap/hardbreak-extension'
import HeadingNode from '@tiptap/heading-extension'

Any thoughts about this? 🤔

[hanspagel]

Nope

[vinerz]

Hey @philippkuehn! I literally spent 10 days trying to figure out the best WYSIWYG for Vue, because everything seemed so locked up and as I need to use JS on demand Font-Awesome Pro Icons, They never allowed me to do so without resorting to shady DOM manipulations inside Vue (which are little abominations and very easy to break).

Finally, after a whole night awake I could find the best and most promising editor of them all! Congratulations for the job. You have saved my life.

As about moving to multiple extensions, I don't personally think it is needed. You could just make individual files and then index.js would export all available extensions.

So I could, for example, import from the package root:

import  {
  BlockquoteNode,
  BulletListNode,
  HardBreakNode,
  HeadingNode,
} from 'tiptap-extensions';

Or if I am very concerned about tree-shaking:

import  BlockquoteNode from 'tiptap-extensions/BlockquoteNode';
import  BulletListNode from 'tiptap-extensions/BulletListNode';
import  HardBreakNode from 'tiptap-extensions/HardBreakNode';
import  HeadingNode from 'tiptap-extensions/HeadingNode';

This way you won't create a breaking change on current implementations. In my opinion, these entities are too small to justify separated packages.

[hanspagel]

Sounds good to me

[qyloxe]

I think, that tree shaking should be considered by app developer and supported by framework not a specific component. For example, Quasar has tight integration with webpack etc. and tree shaking is done automagically for every used component and for every output platform - spa, pwa, electron, cordova etc.

https://quasar-framework.org/guide/index.html

So, I don't think that you should worry about that. TipTap is a component and IMHO it will be almost always used as a part of a greater framework. BTW I would LOVE to see tiptap as a part of quasar...

[erickwilder]

I would say no. Like @vinerz mentioned, tree shaking is possible within a single package. By splitting into multiple packages you'll just add more maintenance burden (to yourself and anyone willing to contribute)

On the other hand, I do think that a scoped package is a neat idea. Go for it

[philippkuehn]

Okay, I'm not gonna move the packages. Thank you for your input ❤️