yarnpkg / yarn

The 1.x line is frozen - features and bugfixes now happen on https://github.com/yarnpkg/berry
https://classic.yarnpkg.com
Other
41.44k stars 2.73k forks source link

`yarn upgrade` (and `npm update` for that matter) doesn't seem to do anything for transitive dependencies. #8901

Closed factoidforrest closed 2 years ago

factoidforrest commented 2 years ago

Let's say you have dependency A which depends on dependency B@^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 npm overrides for this, its a one time fix and the only problem is the lockfile being out of date.

rally25rs commented 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.

factoidforrest commented 2 years ago

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!