Non-blocking linting option about eslint-webpack-plugin HOT 9 CLOSED

@stylemistake
Performance was corrected in v2.5.4

from eslint-webpack-plugin.

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.

from eslint-webpack-plugin.

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.

from eslint-webpack-plugin.

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

from eslint-webpack-plugin.

@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.

from eslint-webpack-plugin.

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?

from eslint-webpack-plugin.

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

from eslint-webpack-plugin.

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.

from eslint-webpack-plugin.

@elisherer
Use threads option

from eslint-webpack-plugin.