-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[turborepo] Newly-cloned git cloned monorepo reports erroneous "cache hit" for a common monorepo lib package #5025
Comments
I realized I shared the turbo.json in a screenshot in the {
"pipeline": {
"build": {
"dependsOn": ["^build"],
"outputs": ["dist/**", "build/**"]
},
"lint": {
"outputs": []
},
"lint:fix": {
"outputs": []
},
"start": {
"dependsOn": []
},
"test": {
"dependsOn": [],
"inputs": ["src/**/*.tsx", "src/**/*.ts"],
"outputs": []
},
"typecheck": {
"outputs": []
}
}
}
|
😄 Thanks for that, I saw that screenshot as soon as I posted the comment! We're looking into this one now. One of the theories is that this is related to a bug the Daemon and our file watching. We do file watching to monitor files that are changed to ensure we only actually restore when things have changed that impact the outputs. That means that you can have remote caching disabled, delete your local cache directory, and still get a cache hit as long as your outputs still exist, and you haven't changed anything related to your inputs. However, a fresh clone and build should definitely not get a cache hit (since outputs should definitely not already exist in this case). |
Thanks for the info and quick response. If I can be of any additional
assistance in the interim, please let me know
|
Did some investigation here, this does look like an issue with the daemon, we're working on a fix, but in the meantime can you verify that running with |
confirmed |
### Description Fixes #5025 In Go code we would shut down the daemon whenever the repository root was removed. This PR adds that logic back by watching the root and exiting the daemon if the root is removed. ### Testing Instructions Added unit test. Follow instructions in reproduction repository in `uncurated-tests/turborepo-netflix-cache-repro` --------- Co-authored-by: Alexander Lyon <arlyon@me.com> Co-authored-by: Chris Olszewski <Chris Olszewski>
### Description Fixes #5025 In Go code we would shut down the daemon whenever the repository root was removed. This PR adds that logic back by watching the root and exiting the daemon if the root is removed. ### Testing Instructions Added unit test. Follow instructions in reproduction repository in `uncurated-tests/turborepo-netflix-cache-repro` --------- Co-authored-by: Alexander Lyon <arlyon@me.com> Co-authored-by: Chris Olszewski <Chris Olszewski>
### Description Fixes #5025 In Go code we would shut down the daemon whenever the repository root was removed. This PR adds that logic back by watching the root and exiting the daemon if the root is removed. ### Testing Instructions Added unit test. Follow instructions in reproduction repository in `uncurated-tests/turborepo-netflix-cache-repro` --------- Co-authored-by: Alexander Lyon <arlyon@me.com> Co-authored-by: Chris Olszewski <Chris Olszewski>
### Description Fixes #5025 In Go code we would shut down the daemon whenever the repository root was removed. This PR adds that logic back by watching the root and exiting the daemon if the root is removed. ### Testing Instructions Added unit test. Follow instructions in reproduction repository in `uncurated-tests/turborepo-netflix-cache-repro` --------- Co-authored-by: Alexander Lyon <arlyon@me.com> Co-authored-by: Chris Olszewski <Chris Olszewski>
@benduran Can you give |
@gsoltis 👋 tried out this morning and I can confirm it's working as expected. Thank you for the swift patch 🍻 |
What version of Turborepo are you using?
1.9.8
What package manager are you using / does the bug impact?
npm
What operating system are you using?
Mac
Describe the Bug
I have one package that is a shared utility library, which is imported by a number of other packages. This package is declared as a
devDependency
to get the NPM Monorepo link, but to keep it out of our consumer'snode_modules
when they runnpm install
.Here is how one of the consuming packages that uses this shared utility library is declaring the monorepo dep:
And here is the shared utility library's
package.json
file:This utility package keeps reporting a cache hit, even after I've blasted everything away in the repo with
git clean -xdf
, which should wiping out the Turbo cache (see images below for behavior):Top-level project folder structure
Monorepo packages folder structure
Erroneous Cache Hit with no
node_modules
folderEven after a fresh repository clone, the package reports a cache hit, which leads me to believe that there's either a bug with the Caching mechanism, or Turbo's Cache location is erroneously reported as
node_modules/.cache/turbo
in the official documentation.Downgrading clear back to
1.6
has corrected this issue, so I am unblocked for now, but I am concerned there's a lingering bug that is causing this issue.Expected Behavior
I would expect there to not be a cache hit, since I blasted away all non-SCM files. I would also not expect a cache hit if I re-cloned the git repository, even if the repository was cloned at some point in the past, but was removed before re-cloning.
To Reproduce
Please refer to screenshots in the bug description. The shared utility library is compiled to plain JS (with
*.d.ts
files) usingtsup
.Reproduction Repo
An internal, enterprise repository
The text was updated successfully, but these errors were encountered: