How to upgrade indirect dependencies?

chinesedfan commented 6 years ago

Do you want to request a feature or report a bug?

Feature.

What is the current behavior? yarn upgrade ignores indirect dependencies, so users can't upgrade them in yarn.lock. If I missed something, please tell me.

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

Suppose a new empty project, run yarn add is-alphanumerical@1.0.0
- 2 indirect dependencies, is-alphabetical and is-decimal, will be installed and saved in yarn.lock
- the latest version of is-alphabetical is 1.0.1 now, if another new version, say 1.0.2 was released(to test, you can release 2 test packages by yourself or modify is-alphabetical to be 1.0.0 in yarn.lock, I know modifying yarn.lock directly is not a regular operation)
No matter which of following ways, yarn always says All of your dependencies are up to date
- yarn upgrade is-alphabetical
- yarn upgrade-interactive
- yarn upgrade-interactive is-alphabetical

What is the expected behavior? yarn upgrade also supports indirect dependencies.

Please mention your node.js, yarn and operating system version. Node 8.9.0 yarn 1.3.2 OSX 10.12.6

ExplodingCabbage commented 2 years ago

The --recursive flag, as in yarn up whatever-package --recursive, appears to make yarn up happy to upgrade whatever-package even if it's a sub-dependency. I'm not sure if this is a bug or not, since my understanding of https://yarnpkg.com/cli/up#options-R%2C-recursive is that the main intent of --recursive is to let you upgrade a specified package's dependencies, not to let you upgrade a specified indirect dependency. But regardless I've found it was good enough for my purposes everywhere I've needed to do an indrect dependency upgrade so far!

Tofandel commented 2 years ago

From the linked issue, it seems this has been resolved already and running yarn upgrade should update indirect dependencies

jrochkind commented 2 years ago

Hi @Tofandel , can you say which linked issue you are referring to? There are several here, I think. I haven't been able to identify one that suggests this issue is resolved.

Do you know what version of yarn resolves the issue?

Have you tried it out yourself to verify, and if so what version of yarn?

It's not working for me, but I have an old version of yarn. I am interested in what version of yarn might resolve it.

Tofandel commented 2 years ago

I'm referring to https://github.com/yarnpkg/yarn/issues/2394#issuecomment-386290827

I don't know which version, but yes for me doing yarn upgrade produces the same as deleting an old yarn.lock and running yarn install

But It might be that all the indirect dependencies upgrades are covered by packages that need direct upgrade

niklasholm commented 2 years ago

@Tofandel yarn upgrade upgrades all dependencies, yes. This issue is about upgrading specific transitive dependencies without upgrading everything.

Tofandel commented 2 years ago

@niklasholm The issue doesn't really say "without upgrading everything"

You can give a try with this package.json and this lock file

{
  "dependencies": {
    "is-alphanumerical": "1.0.0"
  }
}

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

is-alphabetical@^1.0.0:
  version "1.0.0"
  resolved "https://registry.yarnpkg.com/is-alphabetical/-/is-alphabetical-1.0.0.tgz#e2544c13058255f2144cb757066cd3342a1c8c46"
  integrity sha512-qCTN0ODfqBekrQXyHiilXfcZA7hWs3wswkg5jmlKkTVI8IcFwIn33d0kBHpkZGp2/cYNVfASeP/mt/4Dgs84FQ==

is-alphanumerical@1.0.0:
  version "1.0.0"
  resolved "https://registry.yarnpkg.com/is-alphanumerical/-/is-alphanumerical-1.0.0.tgz#e06492e719c1bf15dec239e4f1af5f67b4d6e7bf"
  integrity sha512-vBnURR3j92CuvpwwAHs3nmttKsLPb04UyiSkeJquAaiMXj18Y+T6nBIFOSbBIbbsu5DViJeHdeAy5Sk7Se5S/Q==
  dependencies:
    is-alphabetical "^1.0.0"
    is-decimal "^1.0.0"

is-decimal@^1.0.0:
  version "1.0.4"
  resolved "https://registry.yarnpkg.com/is-decimal/-/is-decimal-1.0.4.tgz#65a3a5958a1c5b63a706e1b333d7cd9f630d3fa5"
  integrity sha512-RGdriMmQQvZ2aqaQq3awNA6dCGtKpiDFcOzrTWrDAT2MiWrKQVPmxLGHl7Y2nNu6led0kEyoX0enY0qXYsv9zw==

Run yarn upgrade

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

is-alphabetical@^1.0.0:
  version "1.0.4"
  resolved "https://registry.yarnpkg.com/is-alphabetical/-/is-alphabetical-1.0.4.tgz#9e7d6b94916be22153745d184c298cbf986a686d"
  integrity sha512-DwzsA04LQ10FHTZuL0/grVDk4rFoVH1pjAToYwBrHSxcrBIGQuXrQMtD5U1b0U2XVgKZCTLLP8u2Qxqhy3l2Vg==

is-alphanumerical@1.0.0:
  version "1.0.0"
  resolved "https://registry.yarnpkg.com/is-alphanumerical/-/is-alphanumerical-1.0.0.tgz#e06492e719c1bf15dec239e4f1af5f67b4d6e7bf"
  integrity sha512-vBnURR3j92CuvpwwAHs3nmttKsLPb04UyiSkeJquAaiMXj18Y+T6nBIFOSbBIbbsu5DViJeHdeAy5Sk7Se5S/Q==
  dependencies:
    is-alphabetical "^1.0.0"
    is-decimal "^1.0.0"

is-decimal@^1.0.0:
  version "1.0.4"
  resolved "https://registry.yarnpkg.com/is-decimal/-/is-decimal-1.0.4.tgz#65a3a5958a1c5b63a706e1b333d7cd9f630d3fa5"
  integrity sha512-RGdriMmQQvZ2aqaQq3awNA6dCGtKpiDFcOzrTWrDAT2MiWrKQVPmxLGHl7Y2nNu6led0kEyoX0enY0qXYsv9zw==

Running yarn upgrade is-alphanumerical will produce the same result

As you can see the transitive is-alphabetical was bumped to version 1.0.4

Edit: Sorry, you're right I was confused by the wording of the original issue and I was not the only one, the comment https://github.com/yarnpkg/yarn/issues/4986#issuecomment-346752906 explains it much better but is a bit too low So the issue is about being able to do yarn upgrade indirect-dependency-name-here specifically instead instead of yarn upgrade direct-dependency to upgrade one subdependency specifically instead of all the subdependencies

jrochkind commented 2 years ago

The entire discussion in this ticket the entire time has assumed "without upgrading everything". If you wanted to upgrade everything, indeed yarn upgrade (without arguments) would have done it, even back in 2017 when this ticket was filed. I think everyone knew that, there was no reason for the ticket to be filed unless it meant "without upgrading everything" so it was assumed without being said explicit in 2017.

Note the examples in the original issue descirption were about trying to upgrade specific deps:

yarn upgrade is-alphabetical yarn upgrade-interactive yarn upgrade-interactive is-alphabetical

Meanwhile, I still am confused about whether this now works in yarn, and if so introduced in what version.

but I don't think I'm ever going to learn it from this ticket, I'll try to find some time to experiment.

Tofandel commented 2 years ago

@jrochkind It still doesn't then, I just tried it

ndp commented 1 year ago

FWIW, I was able to upgrade an indirect dependency using the --recursive flag. In my case, I want to upgrade loader-utils, which is not in my package. json but has a security alert. I was able to run:

yarn up --recursive loader-utils

It modified my yarn.lock, but nothing else. In fact, I was able to take care of three security vulnerabilities this way. For me, this is a workable solution and could simply be documented as the solution unless there are cases that don't work.

$ yarn --version 3.2.0

sbernard31 commented 1 year ago

If you are using old stable version (e.g. 1.22.x) : I didn't find better solution than : https://medium.com/@ayushya/upgrading-javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

matthewtusker commented 1 year ago

If you are using old stable version (e.g. 1.22.x) : I didn't find better solution than : https://medium.com/@ayushya/upgrading-javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

This works far better than any of the solutions listed here. yarn up --recursive loader-utils upgrades loader-utils, but has also upgraded a bunch of other stuff, and has still left to disparate versions. Deleting the lines from the lock file and then running yarn install installs a single version.

pftg commented 1 year ago

If you are using old stable version (e.g. 1.22.x) : I didn't find better solution than : https://medium.com/@ayushya/upgrading-javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

This works far better than any of the solutions listed here. yarn up --recursive loader-utils upgrades loader-utils, but has also upgraded a bunch of other stuff, and has still left to disparate versions. Deleting the lines from the lock file and then running yarn install installs a single version.

@matthewtusker Here is a script that I used to do the same: https://github.com/yarnpkg/yarn/issues/4986#issuecomment-562719589

microJ commented 1 year ago

If you are using old stable version (e.g. 1.22.x) : I didn't find better solution than : https://medium.com/@ayushya/upgrading-javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

work for me. simply, I want to upgrade react-native@0.63.5, then run yarn remove react-native && yarn add react-native@0.63.5 work for me well

safydy commented 1 year ago

the combination of yarn remove & yarn add did work for me as workaround.

yarn remove myPackage; yarn add myPackage

jrochkind commented 1 year ago

the combination of yarn remove & yarn add

I do not believe that works for indirect dependencies -- dependencies not specifically listed in your package.json. That's what this issue is about, it's in the title, "how to upgrade indirect dependencies."

If it does work for indirect dependencies, please confirm, and what yarn version you are using.

I think this zombie issue has become probably unproductive and incoherent at this point.

gonadarian commented 1 year ago

I use the following "clean" approach (without touching yarn.lock) in such situations.

If, as described in original example, we have:

yarn add is-alphanumerical@1.0.0
- installs is-alphabetical v1.0.1

I would do these 3 steps:

yarn add is-alphabetical@1.0.2
- gives duplicated is-alphabetical with both original v1.0.1 & new v1.0.2 in yarn.lock
npx yarn-deduplicate
- deduplicates to only the latest is-alphabetical v1.0.2
yarn remove is-alphabetical
- cleans up package.json
profit!

romainmenke commented 1 year ago

We switched the entire release strategy of postcss-preset-env to accommodate yarn but in hindsight I think this was a mistake. We should have left the issue as is as it wasn't ours to fix.

Our current setup :

build a dependency graph of all parts of postcss-preset-env
check if any part needs to be released
release only those parts that don't themselves depend on unreleased parts
update all downstream dependents with the newly released part's version
go to step 1

We repeat this until the entire graph has been updated and released.

Obviously a small change in a deeply buried part (e.g. a tokenizer) escalates to ±50 releases of packages that didn't themselves have any code changes.

This in turn creates a lot of noice for our users.

We don't like this solution and ideally we wouldn't have to do stuff like this.

We are only doing this because yarn fails to correctly update transitive dependencies, leading to conflicts when peer dependencies are used.

No other package manager is affected by this issue.

rjimenezda commented 2 weeks ago

Hey there.

I am in the process of updating a big workspace where there are many vulnerabilities that would be solved trivially by semver.

An example would be, I have a vitest ^1.6.0 installed, which whenever it was added to the repo, resolved a vite dependency to 5.0.8 (vitest 1.6.0 depends on vite ^5.0.0).

I thought removing the dependency and reinstalling it would upgrade to the latest vite, but if you do so the exact same version of the indirect dependency (vite) is installed.

I would expect there to be a simple way to tell yarn to upgrade a dependency and its dependency tree, or at the very least, letting me do a clean install. I even tried removing vitest 1.6.0 from the local cache, to no avail.

If I initialize a different yarn project and install vitest@^1.6.0 it installs the latest compatible vite version, as semver indicates.

Any workarounds? How does yarn decide to install the exact same version even if I removed it from yarn lock and the cache?

ClementValot commented 2 weeks ago

@rjimenezda Quick idea there for a workaround, you may be able to leverage yarn dedupe

yarn add vite@latest yarn dedupe yarn remove vite

Would install the latest vite version, then deduplicate the vite dependency along semver to only keep the latest, then remove the explicit dependency.

Also, have you checked whether somewhere in your project you would have another transitive dependency to vite which prevents upgrading to somthing higher than 5.0.8? yarn why vite should help in that case

rjimenezda commented 1 week ago

@ClementValot that does work! However, on workspaces is kind of a mess, because it updates all vite uses across the monorepo, not just for the one you are currently on, and we wanted to do these updates gradually.

Also, it still feels incredibly convoluted. I'm still kind of baffled that deleting and reinstalling does not recalculate the most updated subdependencies, while on a fresh yarn project it does. I guess it's an optimization, but I can't figure out how to work around it.

Regarding the second one, no, it does not seem like it. There is a dependency in the middle of vitest and vite, which is vite-node, but yarn why doesn't give any hint as of why it would not work.

rjimenezda commented 1 week ago

I think figured out why vite is not upgraded in that particular case. I'll just type it out in case someone is on the same boat as I am.

Since there are several projects in the monorepo that depend on vites => vite-node => vite@^5.0.0, it seems like for yarn a viteˆ5.0.0 must always be resolved the same way. There is no way to say this particular vite^5.0.0 of this particular dependency chain in this workspace should use version X or Y.

That means, if I want to upgrade vite as an indirect dependency in the monorepo (because of vulnerabilities), I must upgrade it across all projects that depend on the same specified range.

I guess this is a very core design choice that probably has heaps of advantages, it's just kind of annoying for our very particular use case.

yarnpkg / yarn

How to upgrade indirect dependencies? #4986