Closed factoidforrest closed 2 years ago
you are correct, the upgrade
command only checks the direct dependencies, not transitives.
At the time, transitives were a bit odd; Like if the dep tree is
root
+- pkgA
| +- pkgC@^1.0.0
+- pkgB
+- pkgC@^2.0.0
what would yarn upgrade pkgC
do? upgrade both maybe? what of you only want to upgrade one of the transitives?
what I usually do is a manual edit of the yarn.lock
; If you find the transitive dep you want to upgrade in the lockfile, and delete just that package, then re-running yarn install
will pull the latest version for that range. (that package is esentially "unlocked" if you delete it from the lockfile)
So for example, the lockfile wold have something like
pkgA@1.0.0:
version "1.0.0"
resolved ...
integrity ...
dependencies:
pkgC "^1.0.0"
pkgB@1.0.0:
version "1.0.0"
resolved ...
integrity ...
dependencies:
pkgC "^2.0.0"
pkgC@^1.0.0:
version "1.0.0"
resolved ...
integrity ...
pkgC@^2.0.0:
version "2.0.0"
resolved ...
integrity ...
If you just want to upgrade pkgB > pkgC
to say 1.0.1
then just delete the lock entry for pkgC@^1.0.0
pkgA@1.0.0:
version "1.0.0"
resolved ...
integrity ...
dependencies:
pkgC "^1.0.0"
pkgB@1.0.0:
version "1.0.0"
resolved ...
integrity ...
dependencies:
pkgC "^2.0.0"
pkgC@^2.0.0:
version "2.0.0"
resolved ...
integrity ...
Then yarn install
and you would end up with the newest pkgC
that fits the ^1.0.0
range
pkgA@1.0.0:
version "1.0.0"
resolved ...
integrity ...
dependencies:
pkgC "^1.0.0"
pkgB@1.0.0:
version "1.0.0"
resolved ...
integrity ...
dependencies:
pkgC "^2.0.0"
pkgC@^1.0.0:
version "1.0.1"
resolved ...
integrity ...
pkgC@^2.0.0:
version "2.0.0"
resolved ...
integrity ...
Your other deps remain "locked" at the version that is still in the lockfile. This avoids the problem of deleting the entire lockfile and getting upgrades for potentially all your packages.
what would yarn upgrade pkgC do? upgrade both maybe?
I think the default behavior would be to update all of them, that would make complete sense. I understand that yarn@1 is not really making big changes anymore so no point in asking for new functionality or making a PR for that. It's a hard thing to get right. Leave it to renovate and other tools, I guess.
Thanks!
Let's say you have dependency
A
which depends on dependencyB@^1.0.0
and B is installed at 1.0.0 in the lockfile, but 1.1.0 is available and it fixes something important.The classic way to deal with this is to delete the lockfile and reinstall, but since that gets kind of error-prone on large projects, it would be nice be able to update just B and leave the rest of the lockfile instact.
I would expect
yarn upgrade B
to do this, but it doesn't seem to touch transitive instances of B. Am I using this wrong? Is that not an intended use case?I certainly should not have to use
resolutions
or in npmoverrides
for this, its a one time fix and the only problem is the lockfile being out of date.