Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
yesmeck opened this issue Jan 5, 2017 · 27 comments
Closed

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

yesmeck opened this issue Jan 5, 2017 · 27 comments

Comments

@yesmeck
Copy link

yesmeck commented Jan 5, 2017

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
Copy link
Member

arcanis commented Jul 17, 2017

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 arcanis changed the title How to upgrade a sub-dependency? Upgrading sub-dependencies (--nested) Jul 17, 2017
@arcanis arcanis changed the title Upgrading sub-dependencies (--nested) Upgrading sub-dependencies (upgrade --deep) Jul 17, 2017
@arcanis
Copy link
Member

arcanis commented Jul 17, 2017

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

@arcanis
Copy link
Member

arcanis commented Jul 17, 2017

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
Copy link

andvgal commented Aug 22, 2017

@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
Copy link
Contributor

danez commented Sep 22, 2017

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

@rarkins
Copy link
Contributor

rarkins commented Sep 22, 2017

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
Copy link

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
Copy link

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

@NeoLegends
Copy link

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
Copy link
Contributor

bertho-zero commented Nov 2, 2017

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

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

@kaore
Copy link

kaore commented Nov 15, 2017

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
Copy link
Contributor

perlun commented Dec 27, 2017

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

@marcofugaro
Copy link

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

@jasonjifly
Copy link

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
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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

@AlexWayfer
Copy link

@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
Copy link
Contributor

rally25rs commented May 3, 2018

@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
Copy link

AlexWayfer commented May 3, 2018

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
Copy link

@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
Copy link

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

andy7i added a commit to all-of-us/workbench that referenced this issue Nov 27, 2019
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
Copy link

ayushya commented Apr 13, 2020

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
Copy link

flavianh commented Jul 3, 2021

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
Copy link

niklasholm commented Aug 8, 2022

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
Copy link

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"
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests