Yarn: Upgrading sub-dependencies (`upgrade --deep`)

[yesmeck]

Do you want to request a feature or report a bug?
Not sure it's a bug or by design.

What is the current behavior?

yarn upgrade package not upgrade a sub-dependency.

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

Let's say I have a app(https://github.com/yesmeck/yarn-upgrade-test) has following package.json and yarn.lock:

{
  "name": "meck-test-cc",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "meck-test-aa": "^1.0.1"
  }
}

# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1


meck-test-aa@^1.0.1:
  version "1.0.1"
  resolved "https://registry.yarnpkg.com/meck-test-aa/-/meck-test-aa-1.0.1.tgz#bb352b5f5752febe92698712785e7ac0ddee5f00"
  dependencies:
    meck-test-bb "^1.0.0"

meck-test-bb@^1.0.0:
  version "1.0.0"
  resolved "https://registry.yarnpkg.com/meck-test-bb/-/meck-test-bb-1.0.0.tgz#b96934a01e5db227873012c2cf6f9ef8e46b6843"

$ tree node_modules
node_modules
├── meck-test-aa
│   ├── index.js
│   └── package.json
└── meck-test-bb
    ├── index.js
    └── package.json

2 directories, 4 files

After running yarn upgrade meck-test-bb，I got two copies of meck-test-bb:

$ tree node_modules
node_modules
├── meck-test-aa
│   ├── index.js
│   ├── node_modules
│   │   └── meck-test-bb
│   │       ├── index.js
│   │       └── package.json
│   └── package.json
└── meck-test-bb
    ├── index.js
    └── package.json

4 directories, 6 files

What is the expected behavior?

meck-test-bb is upgraged properly.

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

yarn version: v0.18.1

[arcanis]

This is by design - yarn upgrade upgrades your dependencies, not the dependencies of your dependencies. In your case, running yarn upgrade meck-test-bb is similar to using yarn add (you'll see that your package.json file has been updated).

The command is currently being revamped (#3847), but nested dependencies won't be part of this refactoring. Could be an interesting followup, tho - I'm not strongly opposed to adding a --deep parameter to yarn upgrade, so feel free to post a PR!

[arcanis]

Related RFC: https://github.com/yarnpkg/rfcs/pull/54 - but there are extra considerations to take into account :/

[arcanis]

For example, the optimizer might choose to merge together two packages if it respects their dependents version ranges. What should be the upgrade --deep behavior, then? Force upgrade everything to the highest version, disabling optimizations? Or upgrade things to the highest versions, but keep running the optimizer (which means that some packages would not be upgraded)?

[andvgal]

@arcanis Not sure if still open question, but I'd say:

1. Top-level node_modules must always be the latest version satisfying any of dep or sub-deps.
2. dep, sub-dep, sub-sub-dep, etc. node_modules must have own version only if their dependency requirements cannot be satisfied on higher level
   2.1. It's still possible to have duplicates across dependency tree branches - we should warn about that, if not yet.
3. Otherwise, --flat can be used

At the moment, each base dependency release forces re-release of all dependent packages with only package.json file change. That's very questionable for patch & security releases.

I believe the problem is very important as vulnerable package versions may continue to be partially used in application. Also, it breaks all singletons.

[danez]

I wrote a comment here: https://github.com/yarnpkg/yarn/pull/3847#issuecomment-331430517
This was working before #3847 was merged at least when running yarn upgrade without arguments.

[rarkins]

I also think there should be a way to "refresh" a yarn.lock file without needing to rm the existing yarn.lock. For my tool Renovate there is a desire by many users to keep the yarn.lock up to date regularly even if direct dependencies are pinned to exact versions and the only way I've found to do that is to rm -rf the yarn.lock and then yarn install afterwards.

[derwaldgeist]

I just faced this problem when a bug in a deep dependency was fixed, but yarn still installed the version that had been installed at the very first install. Is there an easy way to refresh this?

[marguskoiduste]

Current workaround seems to be yarn remove meck-test-aa and then yarn add meck-test-aa

[NeoLegends]

As seen in https://github.com/DefinitelyTyped/DefinitelyTyped/pull/18738, the absence of this feature creates issues when upgrading typings. This forces us to execute rm yarn.lock && yarn every time we want to upgrade our type definitions.

[bertho-zero]

Any news on this? a --deep option would be welcome.

This issue is problematic when working with a lot of repositories.

[kaore]

It would be handy to have some kind of option to be able to upgrade a package throughout the dependency tree. Having to remove and add a module is a bit tedius. The rm yarn.lock && yarn alternative is not better.

[perlun]

Ran into the very same issue right now... I _can_ handpatch yarn.lock but it feels like a silly way to solve it.

[marcofugaro]

I would also love a yarn upgrade-interactive --latest --deep which would list me also the nested dependencies that need to be upgraded.

[jasonjifly]

Or can we put a yarn.lock file in dependency, when running yarn upgrade, yarn reads the yarn.lockin dependency to see which subdependencies should be used and update the main yarn.lock at the same time.

[AlexWayfer]

My case:

Node.js at developer computer was updated to v10, yarn now gives me:

error [email protected]: The engine "node" is incompatible with this module. Expected version ">=4 <=9".

And I don't want to upgrade all dependencies of postcss-cli:

info Reasons this module exists
   - "postcss-cli#chokidar" depends on it
   - Hoisted from "postcss-cli#chokidar#upath"

[rally25rs]

The original issue has long been fixed. Yarn upgrade will always deep upgrade now. (as a feature request, we might consider adding a --shallow or something like that to revert to the old behavior)

[AlexWayfer]

The original issue has long been fixed. Yarn upgrade will always deep upgrade now.

I think it is not what about this issue:

After running yarn upgrade meck-test-bb，I got two copies of meck-test-bb:

What is the expected behavior?

meck-test-bb is upgraged properly.

[rally25rs]

@AlexWayfer can you open a new issue and include the dependencies from your package.json?

[AlexWayfer]

@AlexWayfer can you open a new issue and include the dependencies from your package.json?

Why new issue about this topic? I have a dependency in my package.json, which depends on b and c packages. I want to upgrade b package without upgrading a or c packages.

Quote from issue starting is above. This issue not about "deep upgrade a package with b and c packages", it's about "upgrade b package as dependency of a package in my package.json".

[rally25rs]

@AlexWayfer sorry for any confusion. you said your issue was

After running yarn upgrade meck-test-bb，I got two copies of meck-test-bb:

which sounded different than the original issue of "sub deps are not being upgraded"

I want to upgrade b package without upgrading a or c packages.

That is not what this issue requested. This issue was that yarn upgrade a was not also upgrading b and c.

---

_edit_

Although re-reading the original issue, I'm not sure that the issue title and actual reported issue were even the same.

Either way, it was reported against yarn v0, and all the upgrade behavior changed or was rewritten for v1. If this is still an issue, a new issue with a fresh thread of conversation specific to yarn v1 would be preferred.

[AlexWayfer]

OK, sorry. I'll start a new issue for my problem.

The title of this issue is just confusing:

Upgrading sub-dependencies (upgrade --deep)

My issue can has the similar…

[chinesedfan]

@rally25rs If this issue is not clear or out-of-date, how about re-opening #4986? It was marked as duplicated with this one.

[AlexWayfer]

@rally25rs If this issue is not clear or out-of-date, how about re-opening #4986? It was marked as duplicated with this one.

Oh, this issue describes exactly what I want! Thank you.

[ayushya]

I was able to resolve deep/indirect dependencies successfully. I wonder when we will get official support.

https://medium.com/@ayushya/upgrading-javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

I have tried to resolve and explained the risks of re-generating the yarn.lock and have suggested what should be done.

Let me know if this works for you guys as well. Or any suggestions to improve the process of upgrading.