-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
chore: more aggressively clean local dev caches #6197
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
chore: more aggressively clean local dev caches #6197
Conversation
Thanks for the PR, @JoshuaKGoldberg! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this!
PR Checklist
Overview
I took another hard look at local build caching w.r.t. #6144 and #6163. I think the issue was that out-of-date files kept getting out of date, most often
packages/types/src/generated/ast-spec.ts
. This adds two layers of protection:types
package, also cleanssrc/generated/
inyarn clean
: since it's generated similar todist/
.yarn clean
in the postinstall script: as a backup precaution to make sure if you've pulled in build/cache changes, to wipe more things that might be out of date now. Ideally Nx should be caching them when the next line'syarn build
runs anyway.I moved the
BaseNode
JSDoc comments to below itstype
as a way to test this. They show up erroneously in the built output so this is a good change anyway. And, #5252 will blow those changes away once v6 lands.