Open chinesedfan opened 6 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!
From the linked issue, it seems this has been resolved already and running yarn upgrade
should update indirect dependencies
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.
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
@Tofandel yarn upgrade
upgrades all dependencies, yes. This issue is about upgrading specific transitive dependencies without upgrading everything.
@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
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.
@jrochkind It still doesn't then, I just tried it
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
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
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.
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
upgradesloader-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 runningyarn 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
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
the combination of yarn remove
& yarn add
did work for me as workaround.
yarn remove myPackage; yarn add myPackage
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.
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
is-alphabetical
v1.0.1I would do these 3 steps:
yarn add is-alphabetical@1.0.2
is-alphabetical
with both original v1.0.1 & new v1.0.2 in yarn.lock
npx yarn-deduplicate
is-alphabetical
v1.0.2yarn remove is-alphabetical
package.json
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 :
postcss-preset-env
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.
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?
@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
@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.
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.
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.
yarn add is-alphanumerical@1.0.0
is-alphabetical
andis-decimal
, will be installed and saved in yarn.lockis-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 modifyis-alphabetical
to be 1.0.0 inyarn.lock
, I know modifying yarn.lock directly is not a regular operation)yarn
always saysAll of your dependencies are up to date
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