turbo: [turborepo] lockfile changes causes all packages to be "changed" when using `--filter=[HEAD~1]`
What version of Turborepo are you using?
1.6.3
What package manager are you using / does the bug impact?
Yarn v1
What operating system are you using?
Mac
Describe the Bug
When any change is added to yarn.lock (even whitespace), running npx turbo run <command> --filter=[HEAD~1] causes the command to be run in every package.
Expected Behavior
I know this is probably a hard one to fix.
But I would prefer if turbo would parse the yarn.lock file and determine if the changed package affects a workspace before executing the command.
To Reproduce
- Create a new turbo repo
- Make a change to the
yarn.lock(even a whitespace is fine) - Commit this change
- Run
npx turbo run build --filter=[HEAD~1]
Reproduction Repo
No response
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 9
- Comments: 16 (4 by maintainers)
Facing the same issue with
pnpm-lock.yaml.any way of preventing this behavior from pnpm ? It’s a pain to run the whole CI because I’ve update one package somewhere
Yes, in our investigations, we’ve more or less isolated the problem to pnpm unexpectedly updating sub-sub-sub-sub-etc dependencies shared by many projects, rather than an issue in Turborepo’s logic.
Hey, folks! This feature has been a part of Turborepo since 1.7. Sorry for only coming across this issue just now!
For the reports that are on this issue that are using 1.7 or later, we’re suspecting that dependencies are being updated deep in the tree, resulting in cache misses, as @EWhite613 has astutely noted. I just did a few similar tests as @EWhite613 and found the expected behavior.
Much of the caching logic around dependencies is drawn off of this logic so we’re pretty confident that we have this working how it should. If you’re still convinced you’re seeing unexpected cache misses, please open a fresh issue with a reproduction so we can take a look.
Very interested in seeing a fix for this as well (we are using
pnpm-lock.yaml)@Marwennnne there is no solution or workaround - I have not got round to fixing it in turbo repo yet. I’m just taking the hit in CI runtime