wbern
commented
2 years ago Bit late to the party but I've opened a discussion about this here. https://github.com/pnpm/pnpm/discussions/4324
Do you have any useful scripts or techniques to share? That would be helpful! (your link is unfortunately 404)
Is this a feature or a bug?
Please describe the actual behavior.
When many team members are working simultaneously in a monorepo, they may change the shrinkwrap file in different ways, causing conflicts when merging in version control. This is disruptive and the least troublesome workaround is to regenerate the file from scratch (beating the point of having a lock file in the first place)
What is the expected behavior?
Ideally, it should be possible for a large number of developers to work in a single repository, making unrelated changes to their dependency sets without causing disruption to work that is unrelated to their own.
I spoke to @iclanton on reddit about this issue and he mentioned there was someone in the team already interest in doing a hackaday project to support emitting logs of transformations and reassembly of shrinkwrap files based on those logs.
If it's helpful at all, my team at Uber (well, mostly myself) has been developing a monorepo management tool somewhat inspired by Rush and we took a different approach: we have individual lockfiles for each project, and tooling to assemble virtual lockfiles (for the purpose of installing dependencies for a graph of local interconnected projects). This tooling dedupes overlapping version ranges and manages incremental modifications of lockfiles. Would be happy to discuss other alternatives (we went through a lot of iterations and lessons learned on this stuff)