search

microsoft / rushstack

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

[rush] Git branch lockfiles of pnpm cannot be used with rush #4819

Open fzxen opened 1 week ago

fzxen commented 1 week ago

Summary

We are trying to migrate the repository to rush. The bad thing is that pnpm lockfile is more likely to conflict than yarn lockfile. Our repo has been suffering from conflict problem recently.

I found that pnpm will carry the information of peerDependencies in the lockfile, and the information is on the same line. if someone change the version of @rushstack/heft, anthoer change the version of @type/node. Conflicts will happen, because they change the same line.

'@rushstack/heft-node-rig':
        specifier: 2.6.15
        version: 2.6.15(@rushstack/heft@0.66.17)(@types/node@18.17.15)(supports-color@8.1.1)

I found that pnpm has the git branch lockfile feature that can completely solves conflict problem even though it brings some challenges to code review. However, it can't be used in rush.

Details

Git branch lockfile can completely solves the conflict problem. However, I can't use this feature in rush. It will cause "rush install" to be unusable When I execute the rush install command, the rush will throw an error：The shrinkwrap file is out of date. You need to run "rush update". Because pnpm-lock.yaml is not match with package.json and rush did not recognize local branch files like pnpm-lock.xxx.yaml.

I have also tried other ways to reduce the probability of conflict：

  1. change the resolution-mode in .npmrc from highest to timed-based. This method can reduce the occurrence of dependencies being bumped.
  2. Use rush subspace feature. This feature can divide pnpm-lock.ymal into multi subspace. However, i found it will create doppelganger dependencies when a package depend on other subspace's packages. It will create a copy of dependency. The package of our repo are close connected. It hard to divide our repo into some unrelated subspaces.
iclanton commented 3 days ago

How do you envision a development workflow going with git-branch-lockfile set to true? Would a large number of branch-specific lockfiles get checked in to the main branch, to be rationalized later?

This also sounds like it would complicates Rush's detection of whether the lockfile is out-of-date.

Would you be interested in putting together a prototype?

fzxen commented 2 days ago

@iclanton

How do you envision a development workflow going with git-branch-lockfile set to true? Would a large number of branch-specific lockfiles get checked in to the main branch, to be rationalized later?

What I currently envision is that when the personal branch is merged into the main branch, a job will be triggered, which will merge all lockflles of the main branch by set merge-git-branch-lockfiles-branch-pattern[]=<main branch> in .npmrc.

This also sounds like it would complicates Rush's detection of whether the lockfile is out-of-date. Would you be interested in putting together a prototype?

I deeply agree with your concern. I'm going to take time to study it.