Threejs cjs and esm confliction since r137

Questions
1

I have some sub projects that have threejs lib in devDependency list, with commonjs webpack dist bundle. In the main app, when yarn link the codebase of sub project, it says “WARNING: Multiple instances of Three.js being imported”.

The problem looks like as below,

With yarn link the sub project source code, it goes to three.module.js, instead it goes to three.cjs. My main app has multiple sub projects, so it’s conflicting in such case.

My usage of all sub projects is

import * as THREE from ‘three’;

This problem happens since r137. It’s also the same problem with sub projects on source code bundle or optimised bundle.

Thanks for any suggestion.

2

The question seems going to the conditional exports,

  "exports": {
    ".": {
      "import": "./build/three.module.js",
      "require": "./build/three.cjs"
    },
    "./examples/fonts/*": "./examples/fonts/*",
    "./examples/jsm/*": "./examples/jsm/*",
    "./src/*": "./src/*"
  }

With source code link, “import” is used, and with commonjs output code link, “require” is used. Can we unify the reference forcely in above case? Probably I should ask webpack…

Thanks

3

Do you import from three/examples/jsm somewhere? Those files are ES modules, and it would probably be necessary to import from three/examples/js instead with your setup. In general I think using ES Modules consistently may work best.

4

Thanks for your reply.

No import three/examples/jsm. After debugging, the problem is, one of the main app dependent libraries uses threejs and output as commonjs module target(usage: require(three)). And the main app also uses threejs(usage: import * as THREE from three). Two threejs involved.

This is a general case:
If someone published a library with threejs in devDependency, and obfuscation out as commonjs module after webpack. Then I used this library and threejs, probably the same problem happens.

5

Hm, yeah this seems like something that might need to be solved at the bundler (webpack, rollup, esbuild, …) level. I would think they could still de-duplicate three even if your dependencies reference three.js with require statements. That said — at this point any npm package depending on three should probably be publishing an ES Module version, that could probably be reported to the npm package issues as well.

6

OK, thanks for your time.