ESLintPlugin not working consistently with cache.type = 'filesystem'

[durad]

Bug report

• OS: macOS Catalina 10.15.7
• node Version: 17.0.1
• webpack Version: 5.64.3
• eslint Version: 8.3.0
• eslint-webpack-plugin Version: 3.1.1

Actual Behavior

With webpack cache turned on and set to 'filesystem' ESLintPlugin reports errors only after first build. If files are unchanged and build is started again ESLintPlugin will not report any errors/warnings.

Expected Behavior

ESLintPlugin should always report same errors/warnings for same input files consistently regardless of the webpack cache.

How Do We Reproduce?

Minimal repo: https://github.com/durad/webpack-eslint-caching-issue

Clone, run yarn install and then run yarn build twice. Warning will be shown only the first time.

Please paste the results of npx webpack-cli info here, and mention other relevant information

~/test/node-14-webpack-eslint * master$ yarn build
yarn run v1.22.10
$ webpack --progress --config=webpack.config.js
asset main.js 28 bytes [compared for emit] [minimized] (name: main)
./src/index.js 66 bytes [built] [code generated]

WARNING in 
/Users/dusan/test/node-14-webpack-eslint/src/index.js
  2:1  warning  Unexpected var, use let or const instead  no-var

✖ 1 problem (0 errors, 1 warning)


webpack 5.64.3 compiled with 1 warning in 358 ms
✨  Done in 0.95s.
~/test/node-14-webpack-eslint * master$ 
~/test/node-14-webpack-eslint * master$ 
~/test/node-14-webpack-eslint * master$ 
~/test/node-14-webpack-eslint * master$ yarn build
yarn run v1.22.10
$ webpack --progress --config=webpack.config.js
asset main.js 28 bytes [compared for emit] [minimized] (name: main)
cached modules 66 bytes [cached] 1 module
webpack 5.64.3 compiled successfully in 209 ms
✨  Done in 0.80s.
~/test/node-14-webpack-eslint * master$ 
~/test/node-14-webpack-eslint * master$ 
~/test/node-14-webpack-eslint * master$ 

Same happens with both development and production mode.

[alexander-akait]

@ricardogobbosouza we should save our warnins/errors in cache and restore it for cached files/modules

[durad]

Is there any progress with this issue?

[ricardogobbosouza]

@alexander-akait
Do you have any webpack cache api documentation?

[alexander-akait]

oh, don't see, let's open an issue in webpack docs site, anyway it is easy, here simple example https://github.com/webpack-contrib/terser-webpack-plugin/blob/master/src/index.js#L334

asset - > getLazyHashedEtag (hash) -> getItemCache (get cached stuff associated with name and hash, because one file (name) can have many cached files with different hashes, for example own file and source maps) -> getPromise (get cached file) -> storePromise (store file in cache)

[alexander-akait]

In your case you need store module (resourcePath maybe?) and associated errors/warnings

[ricardogobbosouza]

Thanks, i will analyze

[kowsen]

Any update on this or ideas for a workaround? This is blocking us from moving to Webpack v5 and we aren't able to come up with a way around it.

Edit: Came up with a gross workaround - if you force ESLintPlugin to run for all files (ignoring the webpack cache) and enable its built in caching, you can get similar build speed without losing the initial lints:

class ESLintPluginNoCache extends ESLintPlugin {
    async run(compiler, ...args) {
        if (!compiler.hooks.compilation.taps.find(({ name }) => name === ESLINT_PLUGIN_NOCACHE)) {
            compiler.hooks.compilation.tap(ESLINT_PLUGIN_NOCACHE, (compilation) => {
                compilation.hooks.succeedModule.intercept({
                    register: (tapInfo) => {
                        if (tapInfo.name === this.key) {
                            compilation.hooks.stillValidModule.tap(this.key, tapInfo.fn);
                        }
                        return tapInfo;
                    }
                });
            });
        }

        return super.run(compiler, ...args);
    }
}

Sadly this setup really chugs if you enable threads and relies so much on ESLintPlugin's internals that it could easily be broken by an update, but it seems to be working well enough for now.

[ricardogobbosouza]

Hi @kowsen
I will look into it soon

[instagibb]

Any progress on this one?

[wz57c]

Has the problem been solved

[SuceV587]

Any chage!