Non-blocking linting option

[elisherer]

• Operating System: N/R
• Node Version: N/R
• NPM Version: N/R
• webpack Version: 4/5
• eslint-webpack-plugin Version: Latest

Feature Proposal

I suggest to add a boolean option nonBlocking (default false).
If turned on, after each code change (while "watching") the linting process will be forked to not interfere with the build process.
(Maybe can tap on the last part of the build process, but still be on another thread)
linting warnings/errors will be shown on console. Not sure it can be shown on the browser console because webpack might not know something happened (maybe someone here knows better).

Feature Use Case

Probably a development only feature:

• The code compilation isn't really affected by lint errors/warnings (usually we use `failOnWarning: false, failOnError: false) . (If there are syntax errors, those will be caught by the transpiler anyway).
• During development, we usually use emitWarning: true so we don't expect the build to fail anyway.
• To boost performance of incremental code changes deferring the linting process will release the hot module replacement (or fast refresh) to see the changes in the browser while still showing lint warnings/errors in the dev server console.

WDYT?

[vegerot]

I'm currently using eslint-loader through vue-cli-plugin-eslint, and I think I have a similar question. I suppose #30 is also relevant

When I set lintOnSave: true, my time it takes for npm run serve to complete quadruples! And the time it takes to recompile for a HMR is 5x longer :( . However, this is not the case for the TypeScript service. For TypeScript, after the devServer finishes compiling and begins serving the page, devServer begins the TypeScript type checking service. Meaning that the type checking does not slow down the server at all, since it is done asynchronously. I was looking into switching from eslint-loader to eslint-webpack-plugin, and one of the main upgrades I was looking for was the ability to lint my codebase in the same way the typechecking service does.

From the sound of this issue, it seems that this is not a feature. Is such a thing on the roadmap?

Right now in eslint-loader, the time it takes to recompile for HMR is unbearable.

[jsg2021]

It's currently not blocking. With or without threads turned on.

[decademoon]

@jsg2021 Are you sure? For me, webpack dev server blocks updates and hot reloads until the linting completes after a watched file has changed. Ideally during development the linting should happen in the background without blocking the webpack build. IIRC there's a typescript loader that works like this.

[jsg2021]

Sorry, I was responding with the definition of classical "blocking"... and it is non-blocking in that sense... execution continues on the main thread while the linter runs in parallel. Webpack is waiting on all async parts to complete the report. Which is the blocking you mean.

[l0gicgate]

I'm curious is there a reason why the eslint-loader did not experience this issue versus the plugin does? Are those changes related to Webpack?

[jsg2021]

@decademoon as of 2.5.0 it is fully blocking. Turn on threads and rollback to 2.4.x...

[stylemistake]

Can confirm, 2.4 is much faster with threads on. I'd suggest reverting whatever was introduced in 2.5.

For comparison on https://github.com/tgstation/tgstation/tree/master/tgui:

• Running executables separately: webpack (20s) + eslint (15s) = 35s;
• Using eslint-webpack-plugin 2.4 with threads: true: 23s;
• Using eslint-webpack-plugin 2.4 with threads: false: 106s;
• Using eslint-webpack-plugin 2.5 with threads: true: 33s;
• Using eslint-webpack-plugin 2.5 with threads: false: 108s;

This was performed on Ryzen 2700X.

[ricardogobbosouza]

@stylemistake
Performance was corrected in v2.5.4

[ricardogobbosouza]

@elisherer
Use threads option