Caching breaks `import/named` rule

[coreyfarrell]

Create test1.js:

export const value = 'test1';

Create test2.js:

import {value} from './test1';

console.log(value);

Run xo, it correctly does not report any errors. Now rename the export in test1.js:

export const value2 = 'test1';

Run xo again, it fails to report any errors. Run touch test2.js && xo, you will see the correct error:

  test2.js:1:9
  ✖  1:9  value not found in ./test1  import/named

  1 error

Locally I just cleared the ~/.xo-cache folder so this resolved the issue for me. Secondary issue, have you considered using ./node_modules/.cache/xo? That would have made it easier for me to find/clear the cache.

[sindresorhus]

If this only happens with import/named, isn't it likely it's a bug with that rule?

[sindresorhus]

have you considered using ./node_modules/.cache/xo?

Yes, I think that would be a good idea. @pvdlg ?

[coreyfarrell]

If this only happens with import/named, isn't it likely it's a bug with that rule?

From what I can tell the issue is that once a file is scanned error free, it is not rechecked unless it's touched. In the example I gave test2.js becomes invalid without being touched, due to a change in test1.js. It doesn't seem like the caching understands that changes to test1.js can invalidate previous results for test2.js.

[sindresorhus]

I think it should be up to eslint-plugin-import to indicate to ESLint when a file needs to be invalidated. ESLint lints per file and doesn't consider relationships between them.

[pvdlg]

Yes, I think that would be a good idea. @pvdlg ?

Yes seems a good idea.

[benmosher]

I think it should be up to eslint-plugin-import to indicate to ESLint when a file needs to be invalidated.

Agreed, but also AFAIK this is not possible, exactly because

ESLint lints per file and doesn't consider relationships between them.

and I would not expect them to bite that off, just for the sake of cache-correctness of the import plugin.