Yarn: Installing wrong version of a package when version is specified as asterisk

[jsdario]

Do you want to request a feature or report a bug?
I am not sure this is a question or a bug. When using yarn in my react-native project I found a behaviour that got me stuck for a couple of hours.

react-native-video-player has specified an asterisk as react-native version.
The rest of my project works on react-native@^0.36.1.

What is the current behavior?
Babel does not compile and throws one after another an error like the following:

Failed to build DependencyGraph: @providesModule naming collision:

Similar to this case https://github.com/aksonov/react-native-router-flux/issues/960.

yarn is installing and locking the latest version for a * (-> 0.37) dependency instead of the most updated compatible one (v0.36.1)

If the current behavior is a bug, please provide the steps to reproduce.
Install or create a project using an older than latest react-native version.
Install a dependency that uses * as version requirement for react-native.

What is the expected behavior?
I believe it should install the most updated compatible version, rather than both the latest and the required.

After all –as stated on npm docs-

• Matches any version

Please mention your node.js, yarn and operating system version.
yarn -> v0.15.1
node -> v5.10.1
Mac OS X

[radiosterne]

Guys, do you have any progress on this issue? In a simple setup with types/react-dom fixed to a specific version and types/react fixed to a specific version as well I'm getting another (latest) version of types/react installed as a sub-dependency into types/react-dom folder, which obviously breaks compilation.

[radiosterne]

Upon further examination, it looks like a duplicate of https://github.com/yarnpkg/yarn/issues/2763 of sorts

[smikula]

I'm experiencing the same thing. While #2763 might provide a way to work around it, this still feels like a legitimate bug. You can repro this in a minimal project with the following dependencies:

"devDependencies": {
    "@types/enzyme": "^2.8.7",
    "@types/react": "^15.6.0"
}

This results in yarn.lock containing:

"@types/react@*":
  version "16.0.10"
  resolved "https://registry.yarnpkg.com/@types/react/-/react-16.0.10.tgz#a24b630f5f1f170866a148a147d4fc8636ea88e0"

"@types/react@^15.6.0":
  version "15.6.4"
  resolved "https://registry.yarnpkg.com/@types/react/-/react-15.6.4.tgz#3bb57bd43183a05919ceb025a264287348f47e9d"

@types/enzyme accepts @types/react@*, so it should just resolve to 15.6.4. Having multiple versions of the typings causes build errors.

[kompot]

Even more confusing when

"@types/react@*", "@types/react@^16.0.18", "@types/react@^16.0.7":
  version "16.0.19"
  resolved "https://registry.yarnpkg.com/@types/react/-/react-16.0.19.tgz#f804a0fcd6d94c17df92cf2fd46671bbbc862329"

after running yarn upgrade-interactive bumps version to 16.0.20 but not the way you'd expect

"@types/react@*", "@types/react@^16.0.18":
  version "16.0.19"
  resolved "https://registry.yarnpkg.com/@types/react/-/react-16.0.19.tgz#f804a0fcd6d94c17df92cf2fd46671bbbc862329"

"@types/react@^16.0.7":
  version "16.0.20"
  resolved "https://registry.yarnpkg.com/@types/react/-/react-16.0.20.tgz#dc16feb9c0bdf50e439482c6fd3c43d5a1d9f3b1"

Even major version is the same.

Basically every yarn upgrade-interactive that is performed should be reviewed so that this bug does not leak into yarn.lock.