Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jsdario opened this issue Nov 11, 2016 · 7 comments
Open

Comments

@jsdario
Copy link

jsdario commented Nov 11, 2016

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 aksonov/react-native-router-flux#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
Copy link

radiosterne commented Aug 2, 2017

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
Copy link

Upon further examination, it looks like a duplicate of #2763 of sorts

@smikula
Copy link

smikula commented Oct 13, 2017

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
Copy link

kompot commented Nov 6, 2017

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.

@cdauth
Copy link

cdauth commented Jun 28, 2022

Are there any updates on this? This remains an issue with Yarn Berry. I have a project that is forced to stick with @types/react@16.8. 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.

@ghost
Copy link

ghost commented Jun 30, 2022

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@*"

@JosephBrooksbank
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants