Upgrading sub-dependencies (`upgrade --deep`) #2394

yesmeck · 2017-01-05T16:34:49Z

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

The text was updated successfully, but these errors were encountered:

arcanis · 2017-07-17T12:46:38Z

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 · 2017-07-17T12:56:18Z

Related RFC: yarnpkg/rfcs#54 - but there are extra considerations to take into account :/

arcanis · 2017-07-17T12:58:55Z

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 · 2017-08-22T21:09:07Z

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

Top-level node_modules must always be the latest version satisfying any of dep or sub-deps.
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.
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 · 2017-09-22T12:18:02Z

I wrote a comment here: #3847 (comment)
This was working before #3847 was merged at least when running yarn upgrade without arguments.

rarkins · 2017-09-22T13:00:08Z

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 · 2017-10-05T08:26:32Z

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 · 2017-10-10T10:10:09Z

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

NeoLegends · 2017-10-19T10:54:37Z

As seen in DefinitelyTyped/DefinitelyTyped#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 · 2017-11-02T16:05:56Z

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

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

kaore · 2017-11-15T17:36:22Z

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 · 2017-12-27T11:37:51Z

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

marcofugaro · 2018-02-07T15:04:48Z

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

jasonjifly · 2018-02-13T09:17:51Z

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

AlexWayfer · 2018-05-03T10:39:37Z

My case:

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

error upath@1.0.4: 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 · 2018-05-03T13:13:15Z

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 · 2018-05-03T13:29:58Z

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 · 2018-05-03T13:42:30Z

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

AlexWayfer · 2018-05-03T14:04:32Z

@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 · 2018-05-03T14:13:02Z

@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 · 2018-05-03T15:10:31Z

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 · 2018-05-03T15:44:32Z

@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 · 2018-05-03T15:46:47Z

@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.

yarn upgrade angular2-highcharts yarn upgrade angular2-highcharts --latest // the sub-dependency has not changed. yarnpkg/yarn#2394 yarn remove angular2-highcharts yarn add angular2-highcharts after all that.... still nothing: dependencies: "@types/highcharts" "^4.2.47" highcharts "^5.0.7" `yarn dev-up` now fails in highcharts/highcharts-angular#107 someone mentioned that setting the version # fixed the issue. Reverted the version number to 2.0.0: `yarn add highcharts-react-official@2.0.0`

ayushya · 2020-04-13T19:19:50Z

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.

flavianh · 2021-07-03T22:34:30Z

If you come across this, here's an alternative to @ayushya 's solution. Yarn actually has a mechanism to handle this case through resolutions in package.json.
The documentation cites as a use case: "A sub-dependency of your project got an important security update and you don’t want to wait for your direct-dependency to issue a minimum version update."

Following the initial example, in package.json:

"resolutions": {
    "meck-test-bb": "^x.y.z"
}

niklasholm · 2022-08-08T14:05:30Z

The resolutions mechanism is a bit blunt for this use case I think. It overrides all transitive versions of a package, even if not necessary, with possibly breaking results if you for example have different major versions of the same package.

williamthorsen · 2022-12-13T09:10:29Z

The resolutions mechanism is a bit blunt for this use case I think. It overrides all transitive versions of a package

resolutions doesn't completely solve the problem, but a pattern can be used to reduce the blast radius:

{
  "resolutions": {
    "dep-with-outdated-transitive-dep/**/transitive-dep": "^x.y.z"
  }
}

OmerHerera mentioned this issue Apr 20, 2017

yarn upgrade breaks dependencies #3202

Open

arcanis added cat-enhancement help wanted labels Jul 17, 2017

arcanis changed the title ~~How to upgrade a sub-dependency?~~ Upgrading sub-dependencies (--nested) Jul 17, 2017

arcanis changed the title ~~Upgrading sub-dependencies (--nested)~~ Upgrading sub-dependencies (upgrade --deep) Jul 17, 2017

arcanis mentioned this issue Jul 17, 2017

yarn upgrade fails to use latest version in deep dependency case #3115

Closed

beseven mentioned this issue Aug 3, 2017

More visibility/flexibility of the number of results returned from search nhsuk/gp-finder#203

Merged

2 tasks

jseppi mentioned this issue Sep 21, 2017

Upgrade hapi to 16.6.0 cloud-gov/pages-builder#54

Merged

NeoLegends mentioned this issue Oct 5, 2017

Types/lodash -- update with new functions DefinitelyTyped/DefinitelyTyped#18738

Merged

14 tasks

bfirsh mentioned this issue Oct 17, 2017

Bump aws-sdk from 2.127.0 to 2.134.0 arxiv-vanity/engrafo#144

Closed

BYK added cat-feature and removed cat-feature cat-enhancement labels Oct 26, 2017

OneCyrus mentioned this issue Nov 27, 2017

How to upgrade indirect dependencies? #4986

Open

rally25rs closed this as completed May 3, 2018

aried3r mentioned this issue Jan 21, 2020

Loosen prosemirror-view dependency nib-edit/nib#93

Open

glasnt mentioned this issue Mar 3, 2020

yarn upgrade beeware/vscode-beeware#26

Merged

SleeplessByte mentioned this issue Jan 29, 2021

--update-db fails with Yarn v2 lock file browserslist/browserslist#577

Closed

JamesSingleton mentioned this issue Jun 30, 2021

fix(deps): upgrade polished dep due to security vulnerability zendeskgarden/react-components#1127

Closed

7 tasks

ansmonjol mentioned this issue Aug 22, 2024

chore: fix ws deep package version getlago/lago-front#1692

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Upgrading sub-dependencies (`upgrade --deep`) #2394

Upgrading sub-dependencies (`upgrade --deep`) #2394

yesmeck commented Jan 5, 2017

arcanis commented Jul 17, 2017

arcanis commented Jul 17, 2017 •

edited

Loading

arcanis commented Jul 17, 2017

andvgal commented Aug 22, 2017

danez commented Sep 22, 2017

rarkins commented Sep 22, 2017

derwaldgeist commented Oct 5, 2017

marguskoiduste commented Oct 10, 2017

NeoLegends commented Oct 19, 2017

bertho-zero commented Nov 2, 2017 •

edited

Loading

kaore commented Nov 15, 2017

perlun commented Dec 27, 2017

marcofugaro commented Feb 7, 2018

jasonjifly commented Feb 13, 2018

AlexWayfer commented May 3, 2018

rally25rs commented May 3, 2018

AlexWayfer commented May 3, 2018

rally25rs commented May 3, 2018

AlexWayfer commented May 3, 2018

rally25rs commented May 3, 2018 •

edited

Loading

AlexWayfer commented May 3, 2018 •

edited

Loading

chinesedfan commented May 3, 2018

AlexWayfer commented May 3, 2018

ayushya commented Apr 13, 2020 •

edited

Loading

flavianh commented Jul 3, 2021

niklasholm commented Aug 8, 2022 •

edited

Loading

williamthorsen commented Dec 13, 2022

Upgrading sub-dependencies (upgrade --deep) #2394

Upgrading sub-dependencies (upgrade --deep) #2394

Comments

yesmeck commented Jan 5, 2017

arcanis commented Jul 17, 2017

arcanis commented Jul 17, 2017 • edited Loading

arcanis commented Jul 17, 2017

andvgal commented Aug 22, 2017

danez commented Sep 22, 2017

rarkins commented Sep 22, 2017

derwaldgeist commented Oct 5, 2017

marguskoiduste commented Oct 10, 2017

NeoLegends commented Oct 19, 2017

bertho-zero commented Nov 2, 2017 • edited Loading

kaore commented Nov 15, 2017

perlun commented Dec 27, 2017

marcofugaro commented Feb 7, 2018

jasonjifly commented Feb 13, 2018

AlexWayfer commented May 3, 2018

rally25rs commented May 3, 2018

AlexWayfer commented May 3, 2018

rally25rs commented May 3, 2018

AlexWayfer commented May 3, 2018

rally25rs commented May 3, 2018 • edited Loading

AlexWayfer commented May 3, 2018 • edited Loading

chinesedfan commented May 3, 2018

AlexWayfer commented May 3, 2018

ayushya commented Apr 13, 2020 • edited Loading

flavianh commented Jul 3, 2021

niklasholm commented Aug 8, 2022 • edited Loading

williamthorsen commented Dec 13, 2022

Upgrading sub-dependencies (`upgrade --deep`) #2394

Upgrading sub-dependencies (`upgrade --deep`) #2394

arcanis commented Jul 17, 2017 •

edited

Loading

bertho-zero commented Nov 2, 2017 •

edited

Loading

rally25rs commented May 3, 2018 •

edited

Loading

AlexWayfer commented May 3, 2018 •

edited

Loading

ayushya commented Apr 13, 2020 •

edited

Loading

niklasholm commented Aug 8, 2022 •

edited

Loading