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: yarnpkg/rfcs#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: #3847 (comment)
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?