Closed laggingreflex closed 7 years ago
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 statestart-simple-cli
is updated to 4.1.1
yarn outdated
in start-webpack
is emptystart-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
?
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"
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.
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?
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)
@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.
@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 https://github.com/yarnpkg/rfcs/pull/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.
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.
Ability to upgrade deep version is quite important, I am looking forward for #54 as well
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.
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.
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 https://github.com/npm/node-semver/issues/79
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 to4.1.0
Installing
start-babel-cli
currently installsstart-simple-cli
v4.0.0
What is the expected behavior?
Installing
start-babel-cli
should installstart-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 installsstart-simple-cli
v4.1.0
)If the current behavior is a bug, please provide the steps to reproduce.
yarn add start-babel-cli
start-simple-cli
start-simple-cli
's versionPlease mention your node.js, yarn and operating system version.