tiptap: v2.0.0-beta.205 breaks strict package managers (monorepos)
What’s the bug you are facing?
Since v2.0.0-beta.205 (introduced day before this issue is posted) prosemirror-* packages are refactored as peerDepdendencies in all tiptap packages, while before that they are dependecies. This IMHO is a very bad move and relies on the default npm behavior to resolve peerDependencies, but it breaks the work of good folks like pnpm, rush, etc that are trying to bring package management to a better place. All those are not resolving auto-magically the peerDeps but are expecting the developer to reference them explicitly.
To understand why this is bad, I was forced to add to my rush monorepo the following dependencies on an application level in order to resolve failing builds:
"prosemirror-commands": "^1.3.1",
"prosemirror-keymap": "^1.2.0",
"prosemirror-schema-list": "^1.2.2",
"prosemirror-dropcursor": "1.5.0",
"prosemirror-gapcursor": "^1.3.1",
"prosemirror-history": "^1.3.0"
The actual dependency depth to @tiptap/* and related with the failing build packages:
app/
apostrophe/
@tiptap/vue-2
@tiptap/extension-highlight"
@tiptap/extension-link"
@tiptap/extension-placeholder"
@tiptap/extension-text-align"
@tiptap/extension-text-style"
@tiptap/extension-underline"
The ApostropheCMS is internally building (Admin UI) @tiptap/vue-2 and extensions in their own build pipeline (webpack) totally independent from the application - you can think of the package apostrophe as a library (sort of). This change forces the ApostropheCMS team to introduce basically all prosemirror-* as direct dependencies in order to not break applications using different than npm (stricter) package manager. This being their responsibility (or any other library implementing tiptap) makes no sense to me.
Which browser was this experienced in? Are any special extensions installed?
Any
How can we reproduce the bug on our side?
Install an apostrophe application in a Rush monorepo. Generally the problem can be observed if @tiptap/* packages are dependencies of root application dependency and the packages are installed via pnpm or rush (I’m sure it breaks a lot more monorepo tools as well).
Can you provide a CodeSandbox?
No response
What did you expect to happen?
Convert the unnecessary peerDependencies back to dependencies.
Anything to add? (optional)
No response
Did you update your dependencies?
- Yes, I’ve updated my dependencies to use the latest version of all packages.
Are you sponsoring us?
- Yes, I’m a sponsor. 💖
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 17
- Comments: 23 (8 by maintainers)
We had a quick talk this morning but were a bit time-capped. While we really don’t like the experience right now (in terms installing all prosemirror-* deps on your own when using pnpm / yarn) we believe it’s kind of the right move.
We’ll have another talk later where we’ll see we can improve this. What we can make sure for now is that we’ll add better documentation for a change like this, for example inside our release note + add new installation instructions to our docs if the peerDependencies stay.
In the end we’ll need to make a decision between:
A. Making sure the installation is easy and uncomplicated but could introduce version clashes with prosemirror as prosemirror is very sensitive with multiple prosemirror versions being loaded which would need some kind of info for Tiptap devs on how to resolve those issues somehow
or
B. Making sure Tiptap works on it’s own and prosemirror needs to be provided by the devs themselves to make sure only one source of truth exists for prosemirror which would lead to a worse setup when it comes to installing and setting up Tiptap which we could and should cushion via better documentation and upgrade guides / notes.
I’ll come back to the issue later with more info
@bdbch Thanks for the quick response and the additional info. We were able to temporary resolve the situation and our builds are working again.
One suggestion though - even if
@tiptap/coreonly introduces peer dependencies (thus the same applies to@tiptap/vue-2) the app developers will end up with the same problem. I fully understand that you (and we all) fight a bad legacy design decisions ofnpm. A good compromise would be an official notifications for a breaking change from your side after your final decision about the peer deps and before the corresponding release implementing it. This would ensure all vendors implementing the library can react and adapt dependencies based on your recommendation beforehand. Breaking change on a beta channel is not exactly semver compliant but in this edge case and with the appropriate communication is an acceptable solution.@myovchev Our new version is released. Make sure to update to
2.0.0-beta.211You can read more here: https://tiptap.dev/blog/new-pm-package-and-upgrade-guide-for-beta-210
Hey @SamuelMS yes I’ll keep you updated as soon as we have news on this. I’ll focus on this issue for this and next week so we should have something up soon.
We added information about the peerDeps in our installation guide in the docs: https://tiptap.dev/installation#1-install-the-dependencies
But I’m also working on a better solution right now that should help out with those long install lines for Tiptap since our team also doesn’t really like the current approach.
What we’re working on is a meta package like
@tiptap/prosemirrorthat you can install to automatically import all required prosemirror dependencies. in combination, you could also access prosemirror exports viaimport { EditorState } from '@tiptap/prosemirror/state.I’m not 100% done as I have to do a bit of an overhaul on our build scripts to separate that build step from the other packages.
I just merged a PR for this which brings a few bigger breaking changes. Keep a look out for the release + new changelog.
First of all, I appreciate your hard work on the great open-source editor 🙏
Though I have to say in this situation DX is far from pleasant because folks on classic yarn 1.x including myself can’t even downgrade back to pre
2.0.0-beta.205I was trying to understand why lock file contains references to 205 when I pin 202. Installing dependencies of tiptap explicitly is forcing people to maintain them.
This is sub-optimal because:
@bdbch Love the idea of a
@tiptap/prosemirrorpackage – we’ll likely hold off on upgrading until that gets set up since our team uses yarn extensively. Should we just keep an eye on #3556 for updates?We are getting this problem only with the
Garpcursorextension.Could this be caused by the tiptap prosemirror tables extension?
my yarn.lock has it as this:
Here is my packages:
However, interestingly enough, I no longer get issues about keys when I drop the
@tiptap/extension-gapcursor@2.0.0-beta.207pluginEven with my resolutions set up and only one version being resolved, I still get complaints about the keys:
The peerDependencies should be auto-resolved when using npm v7+ and not providing the
--legacy-peer-depsflag. The pnpm package manager has a dedicated option for auto resolving peer deps. I’m not aware what’s the situation with yarn. RushJS configured with npm v7+ fails to resolve the newly introduced prosemirror-* peer deps but this seems to be a rush related problem.@bdbch node v14 comes with npm v6 by default. This results in peer deps not being resolved. The easy solution is to explicitly update npm to e.g. v8. This fact might generate a number of failed builds and increased support effort so clearly mentioning it in the docs sounds a wise move. Apostrophe CMS will add notes on that matter in the upcoming release.