using this package in an esm build duplicates prosemirror-* package sources

[benkroeger]

to be honest, this is quite difficult to explain so bare with me...

So in my project I upgraded my prosemirror-state@1.4.0 and prosemirror-model@1.7.0 and found myself facing an error in the browser saying something about trying to load two instances of the same plugin. A long journey of debugging led me to finding the following:

1. ProseMirror's PluginKey Class keeps a local state of what plugin names have been registered
2. Somehow the plugin created by this package uses another PluginKey class than all other plugins in my project
3. When adding all plugin instances to my configuration, there is a conflict for pluginKeys

It appears that this is happening because this package 'only' provides a cjs (or umd) variant and thus when bundling it, its dependencies are resolved according to the dependency's available formats.
I'm using rollup for build / bundle. So when resolving this package's dependencies, it bundles the cjs file from e.g. prosemirror-state/dist/index.js while using prosemirror-state/dist/index.es.js for all other packages.
This leads to prosemirror-state being in the final bundle twice and thus, when invoking PluginKey from this package it hits a different class than all other ProseMirror plugins I'm using.

Besides the runtime errors, this also leads to the bundle being way bigger than it needs to be (due to 'duplicating' code).

The runtime error mentioned initially is gone when I downgrade to prosemirror-state@1.3.4 and prosemirror-model@1.6.1 - while the code duplication is still there (i.e. has been there before, just didn't cause the runtime error)

I know this is a tough one - and I'm not providing any evidence here... simply lack of available time to create a reproduction repo.
Please let me know what is necessary to get this tackled.

[rowanc1]

Very strange. I have tried to solve this in the past by having no direct dependencies for this repo:
https://github.com/curvenote/prosemirror-codemark/blob/main/package.json#L38

All of the dependencies are listed as peers, which means bundlers should handle them externally as your happy path suggests. I have the most experience with webpack, and this is what happens there.

For this repo, it would likely be fine to upgrade the peer dependencies, or maybe leave them more open/unpinned?

Thoughts?

[benkroeger]

hm, there is no conflict in the dependency versions... it's just that prosemirror-* packages have two entry-points... one for require and one for import.
Since releases of this package are transpiled to umd, they use require - while others use import. Hence, they load different files and thus have their own sort of closure for their dependencies (i.e. this package's dependencies are bundled separately)

I believe that publishing this package as both, umd and esm would solve it.
Also, moving from webpack to vite has proven quite simple in the past - and makes these things easier.

[rowanc1]

Fair enough on the publishing as both esm/umd. I will see if I can get to that in the next few days, if I don't happy to take a PR that follows something like this one:
curvenote/prosemirror-autocomplete#8

[rfgamaral]

Hey @rowanc1, I believe I'm having this same issue on our side, and it became especially evident when we updated Tiptap dependencies to the latest versions (which includes updated ProseMirror dependencies too).

To work around the issue, I've forced Webpack to load the root dependency for prosemirror-state instead of letting it figure out what to load, thus avoiding duplicate loading of prosemirror-state. I did that by adding the following to the Webpack final configuration:

resolve: {
    alias: {
        'prosemirror-state': path.resolve('./node_modules/prosemirror-state'),
    }
}

Would be nice to not have to resort to such workarounds, hopefully this can get fixed soon in prosemirror-codemark itself.

Thank you for the time and effort you folks placed on this library.

[rowanc1]

I have tried to address this in #18. Do one of you mind confirming that this actually fixes things in your apps!

[rowanc1]

Can try this on 0.4.0 and let me know how it goes.

[benkroeger]

Will give it a shot soon. Thanks for the effort.

[benkroeger]

yep. like a charme!

[rowanc1]

🚀 Thanks for reporting, and glad it is now fixed!