Linter errors are being cached for errors.js

[tniessen]

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]

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]

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.