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

Linter errors are being cached for errors.js #24202

Closed
tniessen opened this Issue Nov 6, 2018 · 2 comments

Comments

Projects
None yet
3 participants
@tniessen
Member

tniessen commented Nov 6, 2018

I was stuck on this problem for quite some time and only just figured it out thanks to @refack. Basically, I was seeing this error:

/home/tniessen/node/lib/internal/errors.js
  556:1  error  "ERR_CRYPTO_INVALID_KEY_OBJECT_TYPE" is not documented in doc/api/errors.md         node-core/documented-errors
  556:1  error  doc/api/errors.md does not have an anchor for "ERR_CRYPTO_INVALID_KEY_OBJECT_TYPE"  node-core/documented-errors

Even after triple-checking that I documented the error code, the errors didn't go away. I also tried changing the code in tools/eslint-rules/documented-errors.js, but ESLint still printed the errors no matter what I changed the file to.

The solution was to delete the .eslintcache file. Afterwards, the rule seems to have been reloaded and the errors disappeared. I am not sure whether this was caused by our code or by ESLint.

cc @refack
Refs: https://github.com/nodejs/node/blob/master/tools/eslint-rules/documented-errors.js

@Trott

This comment has been minimized.

Member

Trott commented Nov 6, 2018

Even after triple-checking that I documented the error code, the errors didn't go away. I also tried changing the code in tools/eslint-rules/documented-errors.js, but ESLint still printed the errors no matter what I changed the file to.

If ESLint does not detect a change in the file being linted, the ESLint configuration, or the version of ESLint being run, it will use the cache. Unfortunately, that means that changing the plugin code (in tools/eslint-rules/) will not cause it to lint the file again.

I am not sure whether this was caused by our code or by ESLint.

I'm pretty sure that, however this happened, it's an issue with ESLint. I'm going to close this, but feel free to re-open if you think I'm being a bit too hasty about that.

@refack

This comment has been minimized.

Member

refack commented Nov 6, 2018

tl;dr the issue is our rule depends on the content of a 3rd file; doc/api/errors.md. ESLint's cache is unaware of that, so it assumes that if the target file (i.e. errors.js hasn't changed, the rule's output wouldn't change.

I'm pretty sure that, however this happened, it's an issue with ESLint.

I was hoping we could implement a workaround in our rule code, but it seems like ATM we can't - eslint/eslint#11060.

feel free to re-open if you think I'm being a bit too hasty about that.

I'll reopen when there's an upstream solution.

@refack refack changed the title from Linter errors are being cached to Linter errors are being cached for errors.js Nov 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment