Flag --cache does not work in --stdin mode

[utrumo]

Tell us about your environment

Node version: v14.8.0
npm version: v6.14.5
Local ESLint version: v7.7.0 (Currently used)
Global ESLint version: Not found

• ESLint Version:
• Node Version:
• npm Version:

What parser (default, Babel-ESLint, etc.) are you using?
babel-eslint
Please show your full configuration:

Configuration

---
root: true
env:
  browser: true
  node: false
parser: babel-eslint
extends:
  - airbnb
  - airbnb/hooks
rules:
  no-unused-vars:
    - error
    - args: after-used
      argsIgnorePattern: ^_
  no-underscore-dangle:
    - off
  react/jsx-props-no-spreading:
    - off
  react/jsx-fragments:
    - off
  camelcase:
    - off
  react/jsx-filename-extension:
    - off
  no-restricted-syntax:
    - off
  jsx-a11y/label-has-associated-control:
    - error
    - labelComponents:
        - label
      controlComponents:
        - textarea
        - output
settings:
  import/resolver: webpack

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

I use eslint with neovim and coc-diagnostic plugin. It work with stdin mode.
https://github.com/iamcco/coc-diagnostic/blob/301fd84a657594f22f751532bed9f78774919a13/src/config.ts#L12

In this mode, eslint --cache flag does not work and linting is very slow.

cat ./MyComponent.jsx | npx eslint --stdin --stdin-filename MyComponent.jsx --cache --cache-location /tmp/eslint-cache/

What did you expect to happen?
That the --cache key works in stdin mode and and the cache file is created and used

What actually happened? Please include the actual, raw output from ESLint.
Cache file is not created and not used, linting takes a lot of time any time
/home/user/Projects/work/workProject/src/components/Datepicker/Datepicker.jsx
134:5 error Arrow function expected no return value consistent-return

✖ 1 problem (1 error, 0 warnings)

[mdjermanovic]

Hi @utrumo, thanks for the issue!

ESLint's caching doesn't work in --stdin mode. Cache is only used when executing on files, and it's based on file mtime .

Can you add --debug flag to see if something particular takes a lot of time. You can also set TIMING environment variable to see the ten longest-running rules.

[utrumo]

Hi @utrumo, thanks for the issue!

ESLint's caching doesn't work in --stdin mode. Cache is only used when executing on files, and it's based on file mtime .

Can you add --debug flag to see if something particular takes a lot of time. You can also set TIMING environment variable to see the ten longest-running rules.

Hi @mdjermanovic!
I use --stdin-filename flag too and eslint known from it full path to file. Why we can't check mtime by using it?
Look at the validation error log, there is a path:

/home/user/Projects/work/workProject/src/components/Datepicker/Datepicker.jsx
134:5 error Arrow function expected no return value consistent-return

 1 problem (1 error, 0 warnings)

[mdjermanovic]

-stdin-filename option was added for rules that may depend on the filename. It's also useful for projects where different eslint configurations should be applied to different files (for example, if overrides is specified).

Accessing file with the given filename wasn't considered, since the content provided on stdin doesn't have to be the same as the actual content in the file. It could be a change that hasn't been saved yet, so the given -stdin-filename file would still have the same mtime, but the passed content isn't that from the file.

[mdjermanovic]

There is also eslint/rfcs#63 request to optionally use file content (hash) instead of mtime to determine whether a file has changed. However, the caching library we use reads the file independently, so this solution can't be used in the --stdin mode.

[utrumo]

I solved my eslint performance problem - began to use eslint_d npm package, now eslint works extremely fast.

[mdjermanovic]

Glad to hear that!

It seems the problem was with running node.js and loading everything again every time the file is changed, and eslint_d helps to avoid that.

I'm closing this issue since the problem is solved.