@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.lock after a secondary run.
If the current behavior is a bug, please provide the steps to reproduce.
git clone email@example.com: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.
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.