"unpack in the same destination" warning when different semver#^x.x.x points to the same major version

[bulentv]

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
Example project with a main repo (latest v1.0.0), a module (latest v2.0.3) and a shared-module (latest v1.0.1).
Main project is depended on module and shared-module (with semver:^1.0.1)
Module is also depended on shared-module (with semver:^1.0.0)

On main repo, yarn upgrade gives the following warning:
warning Pattern ["test-shared-module@github:bulentv/test-shared-module#semver:^1.0.1"] is trying to unpack in the same destination "/home/bulent/.cache/yarn/v4/npm-test-shared-module-1.0.1-62f4ccb5a503c8f3dd5f11f31cd2c677c7dae722/node_modules/test-shared-module" as pattern ["test-shared-module@bulentv/test-shared-module#semver:^1.0.0"]. This could result in non-deterministic behavior, skipping.

If the current behavior is a bug, please provide the steps to reproduce.

• Create a repo called shared-module project on github and create releases v1.0.0 and v1.0.1
• Create a repor called module-project. Add the share-module#semver:^1.0.0. Create a release (its version is not important)
• Create a main-project and add the both above
  do a yarn upgrade

Example repos mentioned above that you can use to reproduce the issue:
https://github.com/bulentv/test-shared-module
https://github.com/bulentv/test-module
https://github.com/bulentv/test-main-project

What is the expected behavior?
Since shared-module semver#^1.0.0 and shared-module semver#^1.0.1 should both retrieve and extract the latest version of the repo, which is currently v1.0.1, this shouldn't be a problem and the warning should not be generated.

Please mention your node.js, yarn and operating system version.
yarn: 1.12.3
node: v10.14.2
OS: Ubuntu 18.04

[maranomynet]

I'm fighting the same issue, and in my case the main project is depending on github:bar/foo#semver:^2.0.0 plus another module that depends on github:bar/foo#semver:^2.3.1 (note the version order is reversed from OP's example and this still happens).

Yarn copies the module files into node_modules/foo/* but does not run the postinstall script specified in foo/package.json.

My team is using yarn@1.13 on both OSX and Windows10's Linux subsystem.

[maranomynet]

It seems this has been unresolved (and not even acknowledged by the project maintainers) for about 17 months now: #4812

[maranomynet]

...moreover, this only happens when I do a fresh yarn install, but not if I first install foo and then later add the module that depends on foo.

So much for yarn's deterministic behavior... :-(

[maranomynet]

npm install handles this case perfectly, so we're switching back to npm – at least for the time being.

[maranomynet]

Final test: Even locking both dependencies down to the same patch level results in this warning and module foo's postinstall script not running:

Pattern ["foo@github:bar/foo#semver:^2.3.1"] is trying to unpack in the same destination "/Users/baz/Library/Caches/Yarn/v4/npm-qj-2.3.1-[sha-checksum]/node_modules/foo" as pattern ["foo@github:bar/foo#semver:^2.3.1"]. This could result in non-deterministic behavior, skipping.

[Docteh]

@maranomynet sorry to ask 6 months later but were you running yarn on osx? I am currently grasping for straw with a yarn issue on a project that does osx builds.

[maranomynet]

Yes, I am using OSX, yet this (still) is not a OSX specific issue