Consider using eslint-loader `cache` option

[gaearon]

@kentcdodds mentioned he’s not using eslint-loader because of perf issues.
Nobody reported them to us, so naturally we don’t know about them.

What kind of perf issues exist with eslint-loader?
Can you tell me how to reproduce them?

Does enabling that cache option (new in 1.5.0) help, and should we do it?

[gaearon]

cc @andreypopp who might have opinions

[andreypopp]

I don't use CRA with large codebases yet so I don't have perf issues with eslint-loader.

I assume that ESLint's cache option only helps initial linting because otherwise eslint-loader is marked as cacheable and so it lints only changed modules (when in watch mode).

[kentcdodds]

Here's an example. I have experienced this myself on bigger projects. This is why I generally keep eslint out of my webpack stuff and have it as a separate script that I run as a pre-push hook.

[gaearon]

@kentcdodds So the issue is in production builds, or initial npm start? This shouldn’t affect rebuild times in development as far as I understand.

[gaearon]

cc @ericclemmons

[ericclemmons]

@gaearon Unfortunately I can't provide the copy/paste metrics (they were lost in chat long ago, but I can give you near exact info)

• Our typical app start time was ~18 seconds.
• Re-builds (HMR) took ~3s, then ~2s after that. (No idea why sub-sequent re-builds get faster, but they stabilize at the 3rd or 4th re-build).
• I went through every optional plugin (including my own, so totes unbiased) and did a webpack build 5x, and averaged the results.
• No other plugin had a meaningful drop, except for eslint-loader.
• (Note, we weren't aware of the cache option at the time, so this is without it)
• When I removed eslint-loader as a preLoader:
  • Our cold npm start took ~12s (down from ~18s). This is because babel-loader is the 2nd most intensive process in the app.
  • Our warm npm start takes ~8s (just tested it repeatedly), now that most of what babel-loader does it cached.
• Re-compiles (HMR) on the client take ~0.8-1.2s. They hovered around ~1.5-2.4s previously.

As a result, we did the following:

• Remove eslint-loader from the compilation process. Caching may help, but personally we found that stylistic errors shouldn't break the build while syntax errors should, but those are quite visible in the IDE anyway.
• Lint as the first pass in CI, where any output (errors/warnings alike) break the build.

Also, I originally implemented DLLPlugin to resolve speed issues. (You may remember me mentioning it in another CRA thread) Unfortunately, it simply required too much orchestration (especially as the app & deps grew) for the speed gains.

Knowing what I know now, for speeding up builds it would be:

1. Let webpack handle building, and let validation happen elsewhere. (Webpack is optimstic and faster this way).
2. Minimize babel usage. Meaning, if you're running Chrome/Node v6, you can do an entire build without Babel, until you need JSX support. (Of course there are exceptions, but the complete compile down to ES5 is unnecessary IMO for RAD)
3. Reluctantly add DLLPlugin, as this is the closest you'll get to having your app be entirely just ./src.

I hope this helps! We may try this again with cache: true in eslint-loader, but I just don't think it's worth it for me.

[Timer]

Released in 0.9.1/2.