Add --prefer-locked-dependencies option to upgrade command

[atcase]

Summary

When upgrading a dependency, the user does not always want to also update all transitive (sub) dependencies. For example, when locking down or stabilising a system towards the end of a release cycle it may not be the best time to upgrade deep dependencies unexpectedly.

Test plan

yarn upgrade foo works as before, upgrading package foo and all transitive dependenceis

yarn upgrade foo --prefer-locked-dependencies shall ONLY upgrade package foo, retaining any previously locked transitive dependency versions

Fixes #5475

[felixfbecker]

yarn upgrade foo --prefer-locked-dependencies shall ONLY upgrade package foo, retaining any previously locked transitive dependency versions

What if the new version of foo changed a dependency range that requires a transitive dependency to be updated too? I would expect those to get updated too, but only the ones that need to be updated.

[pentaphobe]

Is this dead, or needing some additional love?

[rally25rs]

Looks like there are some linting errors that need to be fixed

yarn lint
yarn run v1.1.0
$ eslint . && flow check

/root/project/yarn/src/cli/commands/upgrade-interactive.js
  34:87  error  Insert `,`  prettier/prettier

/root/project/yarn/src/cli/commands/upgrade.js
  127:16  error  Insert `,`  prettier/prettier
  167:87  error  Insert `,`  prettier/prettier

[rally25rs]

@felixfbecker

What if the new version of foo changed a dependency range that requires a transitive dependency to be updated too? I would expect those to get updated too, but only the ones that need to be updated.

I think this code would do that (but haven't tested it). The updated dep range would not be in the lockfile, so yarn would have to resolve and install it. If an existing installed dep fits the range, then it would use it.

[rally25rs]

Also need to add at least one unit test for this new flag, please.

[timonsdad]

Looks like there's been no movement on this PR in 9 months.

This is functionality that I'd really like to have. If I wanted to pick this up, what would be the best way to proceed, just create a new PR with the same changes + linting corrections + unit tests?

[atcase]

@miokowpak my bad for leaving this stale & thanks very much for offering to pick it up. Based on the comments looks like it needs a remerge / rebase from master to resolve conflicts + the requested changes - not sure why a new PR would be required?

[timonsdad]

@atcase I honestly wasn't expecting you to respond after all this time, which is why I suggested a new PR. Unless I'm overlooking something (which is totally possible), I'll need permission to push to your branch to continue using this PR. If you can set that up, I should be able to get to this, this week.

[timonsdad]

I have added a unit test to verify that this flag works.

@rally25rs I'm really confused by the lint errors and would appreciate some guidance. I am not seeing the lint errors that you mentioned earlier, instead, I'm getting this:

yarn run v1.17.3
warning ../package.json: No license field
$ eslint . && flow check

/tmp/yarn/src/resolvers/exotics/link-resolver.js
  33:31  error  Insert `⏎·····`  prettier/prettier
  34:7   error  Insert `··`      prettier/prettier
  35:1   error  Insert `··`      prettier/prettier

/tmp/yarn/src/util/generate-pnp-map.js
  251:13  warning  Block is redundant  no-lone-blocks

✖ 4 problems (3 errors, 1 warning)
  3 errors, 0 warnings potentially fixable with the `--fix` option.

I attempted to run the linter on master and observed the same issues. My gut feeling tells me that this isn't a problem with this change, but, I'm happy to learn otherwise.

[buildsize[bot]]

File name	Previous Size	New Size	Change
yarn-[version].noarch.rpm	1.18 MB	1.18 MB	1 bytes (0%)
yarn-[version].js	4.85 MB	4.85 MB	340 bytes (0%)
yarn-legacy-[version].js	5.05 MB	5.05 MB	344 bytes (0%)
yarn-v[version].tar.gz	1.18 MB	1.19 MB	2.29 KB (0%)
yarn_[version]all.deb	868.77 KB	868.66 KB	-108 bytes (0%)

[timonsdad]

What if the new version of foo changed a dependency range that requires a transitive dependency to be updated too? I would expect those to get updated too, but only the ones that need to be updated.

I think this code would do that (but haven't tested it). The updated dep range would not be in the lockfile, so yarn would have to resolve and install it. If an existing installed dep fits the range, then it would use it.

I have tested this use case and verified that it does indeed work how you expected.

[timonsdad]

I'm not really sure what to do at this point. Every time I push the same code, different tests pass and fail seemingly at random, not the least bit related to my changes.

[milworm]

Hey, this is a great feature. Would be nice to have it done. @miokowpak just wanted to bring this conversation back to life, the current issue is that some tests fail?

[timonsdad]

The last time I tried, tests would randomly fail in different pipelines. For example, I've seen test-macos-node10 pass, but it failed the last time it ran. None of the failures have ever appeared to be related to changes that I made (although it's possible I just don't understand how they are related). I've rebased onto master a few times hoping I could pull in an update that would fix things, but that didn't work.

My team has changed the way we are doing things, and we no longer need this feature. If there's something easy that I can do to get this working, I'm happy to spend some of my free time, but I don't currently have the time to debug in depth.

[pauldotknopf]

I'm throwing my voice in the mix. I would love to see this feature finalized/deployed/available.

However, I'm hesitant to get in and do it myself because of the testing-related issues reported by @timonsdad :(