v2.0.0-beta.205 breaks strict package managers (monorepos) #3497
Comments
|
duplicate of #3492 |
|
I'm sorry about that, but I wasn't able to find relevant by title issue (the referenced issue is about a concrete implementation). |
|
Hey, just a heads up on this. We moved to We tried to resolve this a few weeks ago by fixing prosemirror versions inside the packages as dependencies but the issue still popped up when users were also adding their own prosemirror versions into their projects. We'll discuss in the team tomorrow what we're going to do with those issues. One thing would be to go back to prosemirror-deps in each extension where they're needed and keep the peerDependency for I'll update this issue when we talked about this. Thanks for your patience |
|
@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 |
|
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 |
|
so now we need to add those peer dependence manually?
|
Not if you install it with npm, since it takes care of peer dependencies |
|
I downgrade to 205 or 2.04 it also throw error, because the starter-kit use the latest core: |
|
I have to add those in packages and it can run |
|
The peerDependencies should be auto-resolved when using npm v7+ and not providing the @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. |
|
We added information about the peerDeps in our installation guide in the docs: 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 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. |
Yes for now. As @myovchev explained this is how for example yarn does package resolving for peer deps. |
|
First of all, 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 I 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:
|
|
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 Even with my resolutions set up and only one version being resolved, I still get complaints about the keys:
|
This indeed sounds like a much more elegant solution. |
|
We are getting this problem only with the |
|
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. |
|
I just merged a PR for this which brings a few bigger breaking changes. Keep a look out for the release + new changelog. |
|
@myovchev Our new version is released. Make sure to update to You can read more here: |
|
@bdbch Does it work with Yarn now? |
|
It should work if you install @tiptap/pm |
I will check it soon! |
What’s the bug you are facing?
Since v2.0.0-beta.205 (introduced day before this issue is posted)
prosemirror-*packages are refactored aspeerDepdendenciesin all tiptap packages, while before that they aredependecies. This IMHO is a very bad move and relies on the defaultnpmbehavior to resolve peerDependencies, but it breaks the work of good folks likepnpm,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
rushmonorepo the following dependencies on an application level in order to resolve failing builds:The actual dependency depth to
@tiptap/*and related with the failing build packages:The ApostropheCMS is internally building (Admin UI)
@tiptap/vue-2and extensions in their own build pipeline (webpack) totally independent from the application - you can think of the packageapostropheas a library (sort of). This change forces the ApostropheCMS team to introduce basically allprosemirror-*as direct dependencies in order to not break applications using different thannpm(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
apostropheapplication 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?
Are you sponsoring us?
The text was updated successfully, but these errors were encountered: