[Bug]: symlinks for js_run_devserver causes duplicate 'node_modules' trees to be seen by bundler (which causes "multiple copies of React" error)

[gregjacobs]

What happened?

When running webpack_devserver() with deps that are a combination of scoped (i.e. @org/*) node modules and non-scoped node modules, Webpack (and other bundlers) see two distinct node_modules trees.

This seems to be because scoped vs. non-scoped modules are symlinked to two different locations in the js_run_devserver sandbox:

1. Unscoped node_modules like 'react' are symlinked to:

   $(bazel info bazel-bin)/node_modules

2. Scoped node_modules like '@my-org/button' are symlinked to:

   $(bazel info bazel-bin)/path/to/serve.sh.runfiles/__main__/node_modules

Below is the Webpack Bundle Analyzer output for the reproduction of this issue at https://github.com/gregjacobs/rules-js-devserver-multiple-react-reproduction:

We see two copies of react.development.js. However, it's all the same 'react' from the repo's root package.json file. And if I change '@my-org/button' to be an unscoped package (just 'button'), everything works as expected.

Some further info:

Unscoped packages are symlinked as:

Scoped packages are symlinked as:

And therefore it seems that transitive dependencies of the scoped @my-org/button package are also resolved under the runfiles node_modules directory, so we end up with:

1. $(bazel info bazel-bin)/node_modules/react (from the app being compiled under Webpack itself)
2. $(bazel info bazel-bin)/packages/app/serve.sh.runfiles/__main__/node_modules/react (transitive dependency of '@my-org/button', which is used in the app)

Version

Development (host) and target OS/architectures: MacOS Monterey

Output of bazel --version: 6.3.1

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file: rules_js@1.31.0, rules_ts@1.4.5, rules_webpack@0.12.0

How to reproduce

See https://github.com/gregjacobs/rules-js-devserver-multiple-react-reproduction

Additional information on the readme.md file there

Any other information?

I commented on #1033 btw but I think this warranted its own issue (as it may or may not solve #1033 since that issue doesn't have a reproduction).

[gregjacobs]

Solved by #1210