Merge conflicts in lockfiles can be pretty gnarly to resolve. Here are my thoughts on how to resolve those safely (using yarn.lock as an example).
TLDR:
Don’t resolve conflicts manually or delete the lockfile. Revert the staged changes to the lockfile and run yarn install again.
Very long, only read if you’re interested:
Resolving merge conflicts manually (or editing a lockfile manually) can be a bad idea. Knowing which changes to accept or reject is very confusing, and manual edits can interfere with tools like yarn or npm’s ability to perform dependency resolution when changes were made to package.json.
It’s tempting to just delete the whole lockfile and regenerate a new one with yarn install, but that’s also a risky thing. Not because the lockfile might be invalid (it won’t) but because what you’re doing is upgrading every dependency all at once (within the version ranges specified in package.json). Keeping dependencies up to date is a good thing, but upgrading everything at once runs the risk of introducing regressions in unexpected places. JS apps rely on a web of interconnected dependencies and subdependencies, and it’s frustratingly easy for minor or even patch upgrades to introduce problems (especially in dev dependencies, which form an absolutely terrible tangled mess in this ecosystem). If every dependency is upgraded, we need to look carefully at the lockfile to see which dependencies have been updated and perform a careful regression test in the parts of our platform that would be impacted.
The safest way to resolve conflicts in the lockfile is to revert the lockfile to its previous state and then run yarn install. Here’s one way to do that when a rebase is paused because of merge conflicts:
First get the commit SHA of the previous commit. Then run git restore --source [commit SHA] [path/to/file]. If you look at the diff for the staged changes to the lockfile, you should see that there are no changes now. This gives you a clean slate to run yarn install, which will update the lockfile appropriately based on the changes in package.json, and then you can stage those changes and continue with your rebase.