Dealing with yarn.lock conflicts

[bagedevimo]

Has anyone come up with a clean way of dealing with yarn.lock conflicts? Yarn itself tries to resolve the conflict using git commit data, but that obviously doesn't work with jj conflict markets (and I don't want to switch to git ones as they're just not as nice IMO). This leads to yarn install with a conflicted file just leaving to yarn exiting with an error, and me cleaning up yarn.lock manually. Just wondering if anyone has come up with any clever tricks for dealing with this better?

[XNinety9]

The git-commit-data part is Yarn Berry's auto-merge: it reads the commit IDs from the conflict markers and asks git for both versions of the lockfile. Even if you switch to git-style markers (--config ui.conflict-marker-style=git), it fails with YN0083: Git returned an error when trying to find the commits pertaining to the conflict, since there's no git merge in progress. (Yarn 1 does accept git-style markers, but not jj's default ones.)

What works for me is to not merge the lockfile at all: resolve package.json first, then take either side of yarn.lock and let yarn regenerate it:

jj resolve --tool :ours yarn.lock
yarn install

yarn install adds whatever the other side introduced, since it's in package.json, and jj picks up the regenerated file as the resolution. To make it a one-liner, an alias in your jj config:

[aliases]
yarn-lock = ["util", "exec", "--", "sh", "-c", "jj resolve --tool :ours yarn.lock && yarn install"]

Then jj yarn-lock after fixing package.json. I tested it with jj 0.45 and both Yarn 1 and Yarn 4: a merge where each side added a different dependency ended up with both in the lockfile and no conflict left.

[bagedevimo]

Oh that's a really nice solution, thank you!