Consider requiring PRs to update pnpm-lock.yaml

For background, there are 3 “levels” of the rush update command, which is used to update the pnpm-lock.yaml file:

1. rush update: Only makes the minimum updates needed to satisfy the package.json files.
2. rush update --recheck: Additional updates to ensure the pnpm-lock.yaml file is consistent with the package.json files.
3. rush update --full: Updates all dependencies to the latest SemVer-compatible version.

rush update -full should be run in a dedicated PR to update all dependencies, so is unrelated to this issue.

This table summarizes the differences between rush update and rush update --recheck. Given a particular source change, is pnpm-lock.yaml updated?

	rush update	rush update --recheck
Add new dependency	yes	yes
Add existing dependency	no	yes
Remove dependency	no	yes

If a new dependency (not use by any other project) is added, both commands will update pnpm-lock.yaml. But if an existing dependency is added or a dependency is removed, then only rush update --recheck will update pnpm-lock.yaml. I believe this is by design and why both commands exist.

Our current workflow is that developers run rush update as part of any PR which might update pnpm-lock.yaml. If a PR adds an existing dependency or removes a dependency, this change will not be reflected in pnpm-lock.yaml until a later time, when another PR adds a new dependency or runs rush update --full.

A “stricter” alternative would be:

1. Developers are expected to run rush update --recheck in any PR that might cause updates to pnpm-lock.yaml.
2. Our pipelines will also run rush update --recheck, and fail if any changes were detected (meaning the PR was missing the changes).

The upside to the stricter version is that pnpm-lock.yaml changes should always be in the same PR as the code changes. The downside is pnpm-lock.yaml will be updated more often, and developers may need to re-submit more PRs with fixes.

I don’t think there is any impact on our shipping packages or validation either way.

[xirzec]

Interesting thing I just discovered. Running rush update --recheck puts our node types up to 10.x, but rush update --full sets it back to 8.x. Not sure why that’s happening, but that could cause us not to want to use recheck in the short term.

[ramya-rao-a]

@praveenkuttappan For completeness sake, we should document similar comparison between the --full and --recheck like how we did above between rush update and rush update --recheck

Regarding the pending issue you referred to, is that being tracked in a separate issue. If not, we can use this issue to do so