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 · 23 comments

Comments

Projects
None yet
@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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

arcanis commented Jul 17, 2017

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

@arcanis

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Copy link

derwaldgeist commented Oct 5, 2017

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?

@NeoLegends NeoLegends referenced this issue Oct 5, 2017

Merged

Types/lodash -- update with new functions #18738

11 of 14 tasks complete
@marguskoiduste

This comment has been minimized.

Copy link

marguskoiduste commented Oct 10, 2017

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

@NeoLegends

This comment has been minimized.

Copy link

NeoLegends commented Oct 19, 2017

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Copy link

marcofugaro commented Feb 7, 2018

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

@jasonjifly

This comment has been minimized.

Copy link

jasonjifly commented Feb 13, 2018

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

This comment has been minimized.

Copy link

AlexWayfer commented May 3, 2018

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

This comment has been minimized.

Copy link
Contributor

rally25rs commented May 3, 2018

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)

@rally25rs rally25rs closed this May 3, 2018

@AlexWayfer

This comment has been minimized.

Copy link

AlexWayfer commented May 3, 2018

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

This comment has been minimized.

Copy link
Contributor

rally25rs commented May 3, 2018

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

@AlexWayfer

This comment has been minimized.

Copy link

AlexWayfer commented May 3, 2018

@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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Copy link

chinesedfan commented May 3, 2018

@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

This comment has been minimized.

Copy link

AlexWayfer commented May 3, 2018

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

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