• I'd be willing to implement this feature (contributing guide)

Describe the user story

As developers using pnpm workspaces (via rush), we experience lockfile conflicts on a common basis.

Thid was recently attempted to alleviate using the text merge driver strategy in Github CI, but unfortunately it seems teams had issues merging these conflicts locally in a way that doesn't break things.

So that leaves the tradeoff that a binary conflict is safer to merge, but causes more conflicts in a PR.

So as a developer, we wish we could stop having a central file between all projects that keeps having conflicts.

Describe the solution you'd like

General

1. Make the pnpm-lock.yaml file ignored by git (.gitignore)

Rush update / pnpm install

1. Assemble a pnpm-lock.yaml file centrally,
2. Run updates on it
3. If successful, copy disassembled versions of it into each package, which can be committed

In a pull request

1. If someone has made changes to the central lockfile, they are basically ignored
2. If someone has made changes that affect a preferred version in all lockfiles, that is still a potential conflict.

Describe the drawbacks of your solution

I'm not quite sure if there are parts of the lockfile that you'd need to duplicate for each lockfile.

Describe alternatives you've considered

Custom merge driver:
Can't be used in github actions

Cron-job for each pull request, updating lockfile:
Works somewhat but feels pretty hacky and will pollute the commit history, and run CI jobs perhaps a bit excessively.

Job that updates all pull requests when main is updated:
Tricky to implement because github actions doesn't give you the pull request context easily from main triggers. Will also still pollute the commit history, and run CI jobs perhaps a bit excessively

Setting merge driver to text:
This is what rush community has recommended but it appears that it's not foolproof for all devs. This might still be possible to explore further, but advice is needed.