search

microsoft / rushstack

Monorepo for tools developed by the Rush Stack community
https://rushstack.io/
Other
5.75k stars 588 forks source link

[rush] update lockfile only #2930

Open chengcyber opened 2 years ago

chengcyber commented 2 years ago

Summary

This is a feature request for rush update, adding a paremeter lockfile-only. When used, only updates pnpm-lock.yaml instead of checking node_modules and downloading dependencies, i.e. internally pnpm install --lockfile-only

Details

pnpm supports --lockfile-only from 1.26.0. see https://pnpm.io/cli/install#--lockfile-only. The only concern is this parameter might be only supports pnpm as packageManager, and turn on useWorkspace option

Use cases

  1. When PR has merge conflict on pnpm-lock.yaml and repo-state.json, developers can fix by rush update --lockfile-only, which is really a life saver.
  2. CI handles merge conflicts. In a CI action, check whether package.json, pnpm-lock.yaml, or repo-state.json is changed. If so, run rush install --check-only. If validation failed, run rush update --lockfile-only to generate the correct lockfile.
  3. In another CI action, triggered when main branch submit or run regularly, do the same logic in 2 to ensure the main branch is always good.
dmichon-msft commented 2 years ago

Might want to check with pnpm, since for a long time the --lockfile-only parameter didn't do much to improve performance; e.g. it still downloaded dependencies. Not sure if that's still the case.

iclanton commented 2 years ago

@chengcyber, can you try adding the argument here on a local branch of Rush to see if performance is noticeably better?

chengcyber commented 2 years ago

Hi, @iclanton @dmichon-msft I do some research locally.

Might want to check with pnpm, since for a long time the --lockfile-only parameter didn't do much to improve performance; e.g. it still downloaded dependencies. Not sure if that's still the case.

This is true, depdencies are still downloaded, which means the most time costing thing seems can not be avoid...

@chengcyber, can you try adding the argument here on a local branch of Rush to see if performance is noticeably better?

Implement the logic locally and run in rushstack repo, the results are

repo time rush update args rush purge before
rushstack 37.23s —recheck yes
rushstack 22.60s —recheck —lockfile-only yes
my repo 6m 58.5s —recheck yes
my repo 6m 16.5s —recheck —lockfile-only yes
rushstack 16.35s —recheck no
rushstack 3.75 —recheck —lockfile-only no
my repo 1m 6.2s —recheck no
my repo 1m 0.3s —recheck —lockfile-only no

Any thoughts?

depressedX commented 3 months ago

any conclusion? every time there is a conflict in pnpm-lock, it becomes so much painful when executing rush update, causing 2min or more to install dependencies