yarn icon indicating copy to clipboard operation
yarn copied to clipboard

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

Open jsdario opened this issue 8 years ago • 6 comments

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

jsdario avatar Nov 11 '16 16:11 jsdario

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 avatar Aug 02 '17 15:08 radiosterne

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

radiosterne avatar Aug 02 '17 15:08 radiosterne

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.

smikula avatar Oct 13 '17 22:10 smikula

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.

kompot avatar Nov 06 '17 12:11 kompot

Are there any updates on this? This remains an issue with Yarn Berry. I have a project that is forced to stick with @types/[email protected]. Plenty of @types dependencies have a dependency on @types/react@*, which yarn resolves to @types/react@18, causing multiple versions of the React typings in my dependencies, which are incompatible with each other and cause type errors. Manually editing yarn.lock worked as a workaround.

cdauth avatar Jun 28 '22 13:06 cdauth

have same issue, sad it lives 6 years.

Make another example, maybe it will help to solve it:

once some package in deps is marked as any * it will be hardcoded in yarn.lock forever. example:

package A has dep:

    "dependencies": {
        "@types/react": "*"
    },

at that moment in yarn.lock will be added record:

...

"@types/react@*":
  version "18.0.14"
...

and there is no way to change this record "@types/react@*"

ghost avatar Jun 30 '22 17:06 ghost

Reporting in almost a year later, having the same issue.

JosephBrooksbank avatar Feb 21 '23 21:02 JosephBrooksbank