Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Eslint is still using the cache when an eslint plugin is updated but the .eslintrc file remain the same
See original GitHub issueTell us about your environment Not related
- ESLint Version:
- Node Version:
- npm Version:
What parser (default, Babel-ESLint, etc.) are you using? Not related
Please show your full configuration: Not related
What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.
eslint --cache --cache-location .eslintcache
(took 4~5 minutes)
eslint --cache --cache-location .eslintcache
(took few seconds)
yarn install --dev eslint-plugin-react-hooks
(2.2.0 -> 2.3.0)
eslint --cache --cache-location .eslintcache
(took few seconds)
eslint --cache --cache-location .eslintcache
(took few seconds)
What did you expect to happen?
eslint --cache --cache-location .eslintcache after version change of any plugins should not using the cache at all.
What actually happened? Please include the actual, raw output from ESLint. It’s still using the cache…
Are you willing to submit a pull request to fix this bug?
Yes, but maybe after some discussion.
currently there is a workaround to include the hash of the yarn.lock or something equivlent to the cache filename.
But I am more towards to have a flag to do something like
“hey, the old cache is not valid any more, let’s create a new one and overwrite the old one”
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Parsing package-lock.json, npm-shrinkwrap.json or yarn.lock, extracting list of all packages that matter (eslint itself, plugins, babel-eslint,…) and including fingerprint of all their versions in part of cache path would solve this I think. Cache wouldn’t be invalidate too often.
Requiring some flag for correct operation in some cases would not be what anyone is expecting to happen.
I would love to see an RFC for this-- I really think this is something we should look at, but as with all core changes, we want to make sure we come up with the best design we can.
If anyone is interested, please feel free to submit an RFC as an issue here: https://github.com/eslint/rfcs. Thanks!