.eslintrc gets loaded hundreds of times when starting webpack-dev-server

[romanzenka]

I am trying to use webpack-dev-server on a project that uses eslint-loader in the 'pre' phase on Windows.

The linting basically doubles the time needed to start the project up.

I see interesting statistics:

2107x opened/closed, 526x read in full .eslintrc
539x opened/closed, 526x time read in full node_modules/eslint-config-airbnb-base/index.js (and other files in that folder)

The total build reads 98MB of data.
Out of that, just eslintrc and eslint-config-airbnb-base combined take more than about 25%.
The main reason for this happening is that the eslint-loader plugin reads tiny files 526 times.

Windows 7 Professional
node 6.9.4
webpack 3.8.1
eslint-loader 1.6.1

[MoOx]

Currently we don't do anything special for the eslint config. We just trigger a linting step on a file via CLI api. That might explain the situation. If you care about speed, you should probably not use this loader on lots of file...

PR welcome to improve the situation.

[romanzenka]

Sounds like EsLint CLI does not support remembering configuration between multiple invocations - the PR will probably have to go to EsLint.

[gaearon]

Can't eslint-loader use a Node API instead of the CLI?

[MoOx]

Probably, but this means that we will have to load configuration ourselves. This means we will require access to how eslint offers looks and load the config.

Problems I see:

• we will have to watch for changes ourselves
• we will have to find a way if people changes from eslintrc to another file etc.

I think that's doable but require some work.

[romanzenka]

@MoOx I think that really is not this plugin's business. That needs to be supported by eslint - basically have it provide API that creates a context that loads the configs and sets up watching and whatnot. Then rapid-fire call "lint this file" on this context object, removing all the initialization overhead. If they do not support this mode, you cannot really implement it for them - that would bloat your plugin considerably and be constant source of pain as you are duplicating their functionality. I did not have time to work with eslint much to see if this can be done and what would it take, but I would hope that for instance eslint integration into IDEs like IntelliJ must work in this mode somehow if it is to be efficient... Not sure how they do that though.

[MoOx]

I totally agree.

[not-an-aardvark]

If you want something to be changed in ESLint, can you create an issue for it on the ESLint repo? I'm not sure it would make sense for ESLint to watch files, but ideally it should provide enough API surface that you don't have to duplicate its functionality in cases like this.

[romanzenka]

@not-an-aardvark We ended up disabling the plugin altogether. We have realized that having a eslint run while we develop in WebPack is problematic.

While developing, the code is in "unclean" state a lot of the time, and that is perfectly okay.
We do want to run linter during the continuous integration step though.

But when we run CI, we do not run eslint through WebPack! We simply run eslint standalone against the whole codebase, since we are testing it all anyway.

So I think that my attempts to get this plugin to perform were misguided - our mistake was that we were using the plugin in the first place.

I am not sure who is this plugin's target audience. I believe large performance improvements are possible, but I do no longer have an incentive to pursue them. Sorry for taking your time!

[Ryuno-Ki]

@MoOx Sounds like this plugin is deprecated then. Would you mind update the README accordingly?

[MoOx]

What is deprecated?

[Ryuno-Ki]

Ah, sorry. I think, I've misread

We ended up disabling the plugin altogether. We have realized that having a eslint run while we develop in WebPack is problematic.

but @romanzenka isn't contributor :-(

[romanzenka]

I am sorry for the confusion - the plugin is great, it just does not really match our workflow. I think it would be most useful for people whose IDE does not have a built-in eslint integration, or for OCD people who need to have every single save of every single file constantly pass linter as they develop. We are in neither of those two camps.