Upgrade dependencies but respect version constraints in package.json

[renchap]

I just migrated to Yarn 2 and it fixed a lot of issues I was encountering with workspaces, while speeding up a lot of things, congrats!

The only problem I have now is to have a way to do what yarn upgrade did in Yarn 1: upgrade all dependencies in my lockfile while not touching my package.json files and respecting the version constraints I wrote.

We are quite careful in specifying our deps constraints (carets vs tilde for example) and do not want our package.json files to change without a manual intervention, but we want to be able to update our packages (and their deep dependancies) to the latest version at once.
Then we look at the still outdated packages, and change the version constraints manually (after checking the changelogs), before running yarn again.

I have not been able to find out how to do this with Berry, even with plugins. I am missing something, or is our workflow out of the ordinary?

Thanks!

[arcanis]

This isn't supported by the CLI. You can fairly easily force ranges to be re-resolved using the JS API, but...

[We] do not want our package.json files to change without a manual intervention, but we want to be able to update our packages (and their deep dependancies) to the latest version at once.

May I ask why? By keeping the existing ranges but upgrading the underlying packages you purposefully end up in a situation where a new hire reading at your package.json would get the wrong impression as to the versions you use. Is there a practical reason for not wanting the manifests to change on upgrades?

[renchap]

Thanks for the answer!
I am not against changing the versions in package.json to match the latest version, but only if it respects the constraint previously set.

For example I currently have typescript: "~4.1.0". I would like to be able to upgrade to version 4.1.5 (the latest version matching my constraint), but currently using yarn up it upgrades to version 4.2.3.
Upgrading to a new TS version can have other implications and will need some work, hence the tilde constraint, but at the same time most packages are using a caret constraint and a single command to upgrade all of those is very handy, especially on big frontend projects with 50+ deps.

Updating the package.json to typescript: "~4.1.5" can work in our workflow, but it is not mandatory (and not the behaviour of yarn upgrade in v1).

[arcanis]

For example I currently have typescript: "~4.1.0". I would like to be able to upgrade to version 4.1.5 (the latest version matching my constraint), but currently using yarn up it upgrades to version 4.2.3.

I see - you can see yarn up as "yarn add but on all workspaces that already list the specified packages"; it doesn't care what's already there. It would make sense to support the workflow you describe as well, but I'm not sure what it would look like - it could easily be an option, but in your case it seems like you'd more often this other behavior than the original one, and I'm not fond of "optional but mandatory to get the intended behavior" options 🤔

[renchap]

As this is the same behaviour as the previous yarn upgrade, can it reuse the same name?

There would be a confusion between up & upgrade, but maybe it can also ease the migration to Berry?

[renchap]

Do you have any pointers on how I could implement a plugin with this behaviour so there is something to experiment with?
I am not familiar at all with Yarn's codebase but I guess I can try to do something if I know where to look at :)