Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All prosemirror packages should be listed as peerDependencies #417

Closed
zanemcca opened this issue Oct 4, 2022 · 2 comments · Fixed by #420
Closed

All prosemirror packages should be listed as peerDependencies #417

zanemcca opened this issue Oct 4, 2022 · 2 comments · Fixed by #420
Assignees
Labels
bug Something isn't working

Comments

@zanemcca
Copy link
Collaborator

zanemcca commented Oct 4, 2022

Description
This issue was posted in Tiptap as well here ueberdosis/tiptap#3209 and I added details in there about how this will manifest into problems.

Long story short prosemirror-* packages are very sensitive to duplicate versions of themselves. If there happen to be two copies of prosemirror-gapcursor for instance you will see the above referenced error. We are often not so lucky to have such a clear error reported though. In my experience things just start failing in unexpected and opaque ways.

The reason these issues occur has to do with how the prosemirror packages were written and there is no real easy solution other than to ensure beyond a shadow of a doubt that you have one and only one copy of each prosemirror-* lib in any given project.

Since all prosemirror packages are defined as dependencies ensuring you have a single copy of each package can be very difficult and error prone for end users.

Please migrate all prosemirror- dependencies to peerDependencies for all of Hocuspocus and TipTap to allow for simple deduplication on our end.

Steps to reproduce the bug
Install Tiptap or Hocuspocus dependencies that result in there being conflicting version requirements for prosemirror-* packages.

For instance I had the following package requirements:

@hocuspocus/transformer@1.0.0-alpha.23
@tiptap/extension-gapcursor@2.0.0-beta.39

The @hocuspocus/transformers resulted in @tiptap/starter-kit@2.0.0-beta.199 being installed which required prosemirror-gapcursor@1.3.1 while @tiptap/extension-gapcursor@2.0.0-beta.39 requires prosemirror-gapcursor@1.3.0.

Expected behavior
There should only ever be a single version of each prosemirror-* package in any project.

Environment?

  • operating system: All operating systems
  • browser: All browsers
  • mobile/desktop: All platforms
  • hocuspocus version: Exists for all current versions but requires there to be mismatches in the underlying prosemirror-* packages for the issues to present themselves.

Additional context
Another variant of this bug
It has been a while since I have seen this variant errors so I am paraphrasing but I often see this issue show up as something along the lines of cannot access <property> of null and when you dig into it the null thing is supposed to reference the particular prosemirror-* Node or Mark or whatever the package provided. It usually fails because the id used to find that package has a similar version supplied by the duplicate prosemirror package.

@zanemcca zanemcca added the bug Something isn't working label Oct 4, 2022
@janthurau janthurau linked a pull request Oct 17, 2022 that will close this issue
@zanemcca
Copy link
Collaborator Author

zanemcca commented Dec 1, 2022

Thanks for patching this @janthurau but I am afraid the problem is still present since tiptap is not importing things as peer dependencies. For instance @tiptap/starter-kit depends on @tiptap/core which depends on prosemirror packages.

This problem is made significantly worse by the fact that overrides are unreliable when working with npm workspaces which drastically limits the options we have to override and resolve things on our end.

Another exacerbating factor is that many projects will be upgrading from old prosemirror editors. For us that necessitates a period where both the old and new editor are built into the same code. This greatly increases the chances of having conflicting packages.

There is a related issue open in tiptap but it has not gotten any attention . I am hoping you can get the ball rolling on this. The above issues have caused our app to break and there do not appear to be any solution that can resolve all of the duplications.

@janthurau
Copy link
Collaborator

hey @zanemcca, thanks for the feedback! I think this is also causing #445, so I've raised it in our internal comms and will try to get prio there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants