Prevent merge of unsynchronized yarn.lock files

[MikeMcC399]

What would you like?

The develop branch should be protected against merging commits with unsynchronized yarn.lock files.

Running yarn on any commit in the develop branch, or destined for this branch, should not produce any differences in yarn.lock.

Why is this needed?

If commits with unsynchronized yarn.lock files are merged into the develop branch then follow-on PRs are forced into cleaning up the mismatch of their predecessor(s) leading to a confusing change history.

Other

Examples of PRs merged with unsynchronized yarn.lock files:

Renovate

See

• Renovate PRs may include yarn.lock with mismatched lockfile #30051

Examples caused by Renovate:

• chore(deps): update dependency multer to v1.4.4 #30008
• chore(deps): update dependency @antfu/utils to ^0.7.8 #29571

Manual error

Caused by manual change to a dependency in a package.json file without running yarn:

• chore: release 13.13.0 #29781 but combined with an unclean PR dependency: update dependency launch-editor to v2.8.0 #29770 from Renovate

[MikeMcC399]

GitHub Actions has a similar issue and https://github.com/cypress-io/github-action/blob/master/.github/workflows/check-dist.yml is used to check for unresolved changes.

That would be something like the following, added into the CI workflow at some point after yarn install has run:

if [ "$(git diff --ignore-space-at-eol | wc -l)" -gt "0" ]; then
    echo yarn.lock mismatch
    git diff
    exit 1
fi

[jennifer-shehane]

Yah, seems reasonable to have something in place since this keeps happening.

[MikeMcC399]

• PR chore: Run renovate with yarn deduplication highest strategy #30060 has solved the regularly recurring issue for Renovate-generated PRs.
• This issue is nevertheless still relevant to catch manual mistakes even though they happen much less frequently than the Renovate issues were previously occurring.

[MikeMcC399]

• Possibly branch protection rules for develop need revisiting.

• PR chore(deps): migrate to @tanstack/react-query #30154 was clean in its own forked branch before merge, but has caused yarn.lock to become out of sync after merge. Was this because it wasn't up to date with develop at the time of merge? If the GitHub UI is used update a branch from develop does that cause a yarn de-duplication run?

[raygdev]

• Possibly branch protection rules for develop need revisiting.
• PR chore(deps): migrate to @tanstack/react-query #30154 was clean in its own forked branch before merge, but has caused yarn.lock to become out of sync after merge. Was this because it wasn't up to date with develop at the time of merge? If the GitHub UI is used update a branch from develop does that cause a yarn de-duplication run?

@MikeMcC399

I did actually consider this when I started making changes. I ended up stashing the changes. I then ran git clean -xfd to remove the node modules. Pulled against the develop branch from cypress to ensure the latest changes, and manually added @tanstack/react-query to the package.json of that directory since the workaround for yarn add didn't work for me. I then ran yarn to install, made changes (not from my stash), and committed them. My initial commit wasn't a semantic release, so I also ran git --amend to change the commit message to suit the requirements of the semantic release. Do you think that may have caused the issue?

Was there something I could have done differently? I would like to make sure that for any future changes I make that this won't be a burden on anyone.

[MikeMcC399]

@raygdev

Was there something I could have done differently? I would like to make sure that for any future changes I make that this won't be a burden on anyone.

The final state of your branch looks completely correct to me, so please don't worry that you did something wrong!

This issue is about improving the process to catch any mismatch issues caused by whatever reason. If there is a mismatch there should be a warning, however there wasn't a warning. I only noticed the problem when I was preparing a new PR and ran yarn which produced yarn.lock changes that had nothing to do with the changes in my new branch.

• chore: Run renovate with yarn deduplication highest strategy #30060 fixed one issue in this area, however it looks like there are still some other gaps in the process. Stay tuned!

[raygdev]

@MikeMcC399
Good to know! I just wanted to make sure that a command I ran wouldn't have caused this issue or that there was something in the process i could have done to prevent it. Will keep an eye on this! Thank you!