Should we move all extensions to its own package?
See original GitHub issueI 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? 🤔
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (4 by maintainers)
Top Results From Across the Web
How to manage packages and extension packages
I think Extensions is what you need to use - I would store all the common code in a 'core' package and have...
Read more >How to Export Chrome Extensions
When the new window appears, select Browse, choose the folder that you've moved to the desktop and click OK. Select the Pack Extension...
Read more >Including plugins in your package
You can include plugins and extensions for apps that are previously installed on your users' computers.
Read more >Managing Extensions in Visual Studio Code
Discover, add, update, disable and uninstall Visual Studio Code extensions (plug-ins) through the Extension Marketplace.
Read more >Automatically install apps and extensions
Most Chrome apps and extensions are in the Chrome Web store. You can also ... Go to the app or extension that you...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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:
Or if I am very concerned about tree-shaking:
This way you won’t create a breaking change on current implementations. In my opinion, these entities are too small to justify separated packages.
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…