Multiple import of YJS warning (with a twist)

1

I’m seeing the infamous “Yjs was already imported. This breaks constructor checks and will lead to issues! - Yjs was already imported. · Issue #438 · yjs/yjs · GitHub” issue (I’ve read the entire issue discussion). The twist here is I’m not importing it multiple times. I specifically use a single version from an in house shared library within my multi module project, which is re-exported and used wherever I need it. So not only are there not multiple versions, but I can ensure there is a single referentially identical Y instance everywhere. I have also confirmed that “yarn why” yields a single version: 13.6.11.

Is it possible that this warning is being presented spuriously? Is there any way to check that I either do or do not have an actual issue?

thanks!

2

If you’re seeing the warning, it means you probably do have the issue.

Note that the warning is not only triggered when importing multiple npm versions, but also when importing the same version in multiple ways, e.g. CommonJS and ESM, as happened recently here.

I wish we had a more systematic way to troubleshoot this issue. Developers should not have to be experts in module and bundling systems (of which I am surely not) just to use YJS.

3

For some context, I can guarantee that within the source code I control it is only ever imported in one way. However, it’s possible that some library I depend on is importing it in a different way. If that is what is triggering the warning, does this imply that every library/source file in a project, all the way down the dependency tree, has to agree on a single way of importing YJS?

4

That’s a great question. I hope that isn’t the case, but I have seen it cause problems for people.

5

Taking a slightly different tack here, I can also guarantee that the only library that is used to act on my YDocs is YJS. No other library directly or indirectly is operating on them. Whether they could or not is an open question, but I’m not passing in my YDocs to any library/source code other than my own and YJS. Is it possible to describe what errors could in practice be caused by the constructor checks under this limited scenario?

6

Unfortunately I’m not knowledgeable enough to comment on those specific questions, but maybe someone else here can chime in.

Maybe you can add a console.trace directly to the YJS dist in your node_modules in order to see what is importing it.

7

For posterity, here’s what worked in my specific case. I was using rollup and yjs was a dependency at multiple levels of my dependency tree, even within my own source. However, I hadn’t listed yjs as an external in the rollup config. It was getting bundled in multiple times, all accessed via esm import, but with referentially distinct (and version equal) instances of the yjs constructor. With external yjs my top level application provided the single instance to be used everywhere.

rollup config (to be used at all dependency levels except topmost):

export default {
    input: '...',
    external: ['yjs'],
    output: [
        ...
    ],
    plugins:[
        ...
    ]
}

Hope this can help someone

2 Likes
8

@santanubasu Glad you figured it out. If you wanted to add your solution to the issue as well, it could be helpful since most people running into the problem will end up there first.

9

Will do, thanks for chiming in on this

1 Like