bun install --linker=isolated is not deterministic #23548
Description
What version of Bun is running?
1.2.23+cf1367137
What platform is your computer?
Linux 6.11.0-1018-azure x86_64 x86_64
What steps can reproduce the bug?
Running bun install --linker=isolated with workspaces using multiple versions of the same module.
Reproduction repo: https://github.com/rochdev/bun-install-non-deterministic-repro
Here we can see collections 5.0.0 is being used in the root node_modules: https://github.com/rochdev/bun-install-non-deterministic-repro/actions/runs/18448786208/job/52559363793 (passing cases in CI)
Here we can see collections 2.0.3 is being used in the root node_modules: https://github.com/rochdev/bun-install-non-deterministic-repro/actions/runs/18448786208/job/52559363803 (failing cases in CI)
What is the expected behavior?
Only one of the cases mentioned in the reproduction should ever happen when running the same command, not multiple seemingly randomly.
What do you see instead?
Random version is picked and linked in node_modules/.bun/node_modules, resulting in a non-deterministic install and by extension a non-deterministic runtime behaviour.
Additional information
Is it even expected that node_modules/.bun/node_modules exists at all with the isolated linker? That technically breaks isolation, as even if the module that is added to that folder would be deterministic, it means that it would become available to all workspaces even if they don't have an explicit dependency on it.
This is basically what we're observing from the reproduction, where q tries to use a file that is not available in the version of collections it depends on, so Node continues searching for it up the tree, and eventually finds it in a different version of collections depended on by a different workspace which gets added to node_modules/.bun/node_modules. Right now it sometimes works and sometimes fails because of the non-deterministic behaviour, but even if this was deterministic, it would technically still be incorrect from an isolation perspective, as whether the module can be accessed would depend on another workspace installing it, which it may not or may use a different version in the future.
Basically, if we evaluate the key benefits from the doc:
Prevents phantom dependencies — Packages cannot accidentally import dependencies they haven't declared
This is not true, as demonstrated in the reproduction q is able to import a version of collections it doesn't depend on.
Deterministic resolution — Same dependency tree regardless of what else is installed
Also not true, as demonstrated in the reproduction different versions of collections can get installed in the root node_modules from one run to another.
Better for monorepos — Workspace isolation prevents cross-contamination between packages
Also not true, as demonstrated in the reproduction q uses a version of collections installed by another workspace.
Reproducible builds — More predictable resolution behavior across environments
Also not true, as non-deterministic behaviour means non-reproducible build.
All of which is why I'm starting to think the problem may not even be with determinism, but maybe these dependencies are not even supposed to be added to the root node_modules folder at all.