@arcanis this started happening fairly recently. I'm not sure if this is a regression due to 1.21.1, or the new fsevents release (or something else entirely).

Do you want to request a feature or report a bug?
Bug. Probably affecting many out there.

What is the current behavior?
yarn changes yarn.lock after a secondary run.

If the current behavior is a bug, please provide the steps to reproduce.

https://github.com/wixplosives/sample-monorepo

git clone [email protected]:wixplosives/sample-monorepo.git
cd sample-monorepo
rm yarn.lock
yarn # generates a fresh new yarn.lock file
rm -rf node_modules # important, otherwise bug doesn't happen
git add yarn.lock # to be able to see whether lock file changed
yarn
git status
# bug is here. "modified:   yarn.lock"

What is the expected behavior?
A fresh install of yarn should generate a "final" lock file. Running yarn on the generated yarn.lock should not change it unless a version request was changed (someone modified package.json since lock file generation).

Please mention your node.js, yarn and operating system version.
yarn 1.21.1
node 12.13.1
fedora 31

Observations
fsevents released a new node12 compatible version (v1.2.11). yarn picks that version up. it's an optional dependency of chokidar. older versions of fsevents had node-pre-gyp as a dependency, and that seems to be the major change in the lock file. not sure if it's related, but perhaps you'll know more. Should be noted that fsevents does not end up installed (optional dep) on non-darwin machines, such as my linux machine.