-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Comments
This is by design - 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 |
--nested
)
--nested
)upgrade --deep
)
Related RFC: yarnpkg/rfcs#54 - but there are extra considerations to take into account :/ |
For example, the optimizer might choose to merge together two packages if it respects their dependents version ranges. What should be the |
@arcanis Not sure if still open question, but I'd say:
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. |
I wrote a comment here: #3847 (comment) |
I also think there should be a way to "refresh" a |
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? |
Current workaround seems to be |
As seen in DefinitelyTyped/DefinitelyTyped#18738, the absence of this feature creates issues when upgrading typings. This forces us to execute |
Any news on this? a This issue is problematic when working with a lot of repositories. |
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 |
Ran into the very same issue right now... I can handpatch |
I would also love a |
Or can we put a |
My case: Node.js at developer computer was updated to v10,
And I don't want to upgrade all dependencies of
|
The original issue has long been fixed. Yarn upgrade will always deep upgrade now. (as a feature request, we might consider adding a |
I think it is not what about this issue:
|
@AlexWayfer can you open a new issue and include the dependencies from your package.json? |
Why new issue about this topic? I have Quote from issue starting is above. This issue not about "deep upgrade |
@AlexWayfer sorry for any confusion. you said your issue was
which sounded different than the original issue of "sub deps are not being upgraded"
That is not what this issue requested. This issue was that 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. |
OK, sorry. I'll start a new issue for my problem. The title of this issue is just confusing:
My issue can has the similar… |
@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`
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. |
If you come across this, here's an alternative to @ayushya 's solution. Yarn actually has a mechanism to handle this case through Following the initial example, in "resolutions": {
"meck-test-bb": "^x.y.z"
} |
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. |
{
"resolutions": {
"dep-with-outdated-transitive-dep/**/transitive-dep": "^x.y.z"
}
} |
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:
After running
yarn upgrade meck-test-bb
,I got two copies ofmeck-test-bb
: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: