Yarn doesn't install the latest versions of transitive dependencies

[laggingreflex]

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

bug

What is the current behavior?

There's a package start-babel-cli that uses {"start-simple-cli": "^4.0.0"}

start-simple-cli has been updated to 4.1.0

Installing start-babel-cli currently installs start-simple-cli v4.0.0

What is the expected behavior?

Installing start-babel-cli should install start-simple-cli v4.1.0 as that's the latest version and respecting the semver as a valid minor bump, this version should be the one that's installed (right?).

I've made sure to clean all cache before testing this.

npm behaves exactly like this (i.e. it correctly installs start-simple-cli v4.1.0)

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

1. yarn add start-babel-cli
2. it should also install start-simple-cli
3. check start-simple-cli's version

Please mention your node.js, yarn and operating system version.

node -v
v7.0.0
npm -v
3.10.8
yarn --verbose
yarn install v0.18.1
ver
Microsoft Windows [Version 10.0.14946]

[deepsweet]

• start-webpack relies on "start-babel-cli": "^4.0.1
• start-babel-cli relies on "start-simple-cli": "^4.0.0"
• start-webpack has yarn.lock with start-simple-cli@^4.0.0: version "4.1.0" last state
• start-simple-cli is updated to 4.1.1
• yarn outdated in start-webpack is empty
• start-simple-cli in dependency of dependency of start-webpack can be updated only with random and blind yarn upgrade

shouldn't yarn outdated show me start-simple-cli? if not then how should I know that something is outdated and I have to run yarn upgrade?

[jkillian]

Think I had this issue show up today: I ran yarn upgrade @blueprintjs/core which correctly upgraded the package, but kept an older version around for transitive dependencies:

Before yarn upgrade @blueprintjs/core

"@blueprintjs/core@^1.0.1", "@blueprintjs/core@^1.1.0", "@blueprintjs/core@^1.5.0", "@blueprintjs/core@^1.7.0":
  version "1.7.0"

After yarn upgrade @blueprintjs/core:

"@blueprintjs/core@^1.0.1", "@blueprintjs/core@^1.1.0", "@blueprintjs/core@^1.5.0", "@blueprintjs/core@^1.7.0":
  version "1.7.0"
...
"@blueprintjs/core@^1.8.0":
  version "1.8.0"

[fmauNeko]

I just had the same issue today when upgrading jest from ^18.0.0 to ^19.0.0, which depends on jest-cli ^18.0.0 that was also switched to ^19.0.0.
Yarn install on my CI did update jest to 19.0.0, but jest-cli stayed at version 18.x.x.
The yarn upgrade I did on my desktop before comitting everything correctly updated the lockfile with the right package.

[bgentry]

Is there any way to get Yarn to upgrade a transitive dependency? I'm using ember-d3, which specifies d3 ^4.0.0 in its package.json and has 4.6.0 in its yarn.lock. Yet my app is locked to v4.4.0 in yarn.lock. Running yarn upgrade d3 adds a new d3 entry to my package.json dependencies section, but ends up leaving the v4.4.0 version vendored into node_modules/d3-ember/node_modules/d3.

How would I get Yarn to respect the package.json specification for ember-d3 and allow me to use a newer version of d3 if I choose?

[laggingreflex]

This has actually saved me a couple of times in the past weeks. Some libraries had introduced breaking changes in minor or patch versions which broke the build when installed with npm but worked when installed with yarn (without yarn.lock existing).

This bug, when fixed, should probably be added as an optional feature-- an option to install exact versions of transitive dependencies (even without yarn.lock)

[dfreeman]

@bgentry I've gotten in the habit of removing and re-adding the root dependency(/ies) to force an upgrade of the transitives, so in your case yarn remove ember-d3 && yarn add (--dev) ember-d3 would also update the d3 version to the latest compatible version.

Ultimately the control given by a change like this proposal would be fantastic and make this all a lot easier.

[bgentry]

@dfreeman heh, apparently that's all I needed to do :)

But yeah, there should definitely be a way to do this without having to re-add the dependency! Tracking yarnpkg/rfcs#54 now

And I agree w/ @laggingreflex that it's essential to be able to specify an exact version of a transitive dependency if desired. Following #2981 as well.

[bestander]

1. So to the original question, Yarn should respect semver of transitive dependencies.
   The original issue does not reproduce anymore

bestander@bestander-mbp ~/w/t/3514> yarn add start-babel-cli
yarn add v0.26.0
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 3 new dependencies.
├─ resolve-cwd@1.0.0
├─ start-babel-cli@4.0.1
└─ start-simple-cli@4.1.1
Done in 7.14s.

2. Ability to upgrade deep version is quite important, I am looking forward for Switch from node-tar to tar-fs #54 as well

3. In larger projects we don't want to have 10 different versions of start-babel-cli, so Yarn may pick 1 that fits 10 different semvers even if it is not the highest version.
   This would optimize for installation time, disk size and consistency across the app.

I'll close the issue for now as I don't see how we can act on it.

[skeggse]

I believe I'm able to reproduce the original issue with live-set and zen-observable. zen-observable has a published version at 0.6.0, but installing live-set which references zen-observable@^0.5.2 installs 0.5.2 instead of 0.6.0.

$ yarn add live-set
yarn add v1.3.2
[1/5] 🔍  Validating package.json...
[2/5] 🔍  Resolving packages...
[3/5] 🚚  Fetching packages...
[4/5] 🔗  Linking dependencies...
[5/5] 📃  Building fresh packages...
success Saved lockfile.
success Saved 10 new dependencies.
├─ asap@2.0.6
├─ babel-runtime@6.26.0
├─ core-js@2.5.1
├─ envify@4.1.0
├─ esprima@4.0.0
├─ live-set@0.4.2
├─ regenerator-runtime@0.11.0
├─ symbol-observable@1.0.4
├─ through@2.3.8
└─ zen-observable@0.5.2
✨  Done in 1.31s.

EDIT: Incorrect report; I mistakenly conceived of the ^ designation as pinning the major version instead of the leftmost non-zero version.

[sethidden]

Hello, hope everyone in this thread has been having a nice life in the last 7 years.

Anyway, as the poster above said, you may be running into npm/node-semver#79