Improve the performance of config generation

[eliperelman]

Not sure how this would work yet, but it would be great to cache the accumulation of middleware between command runs. Some sort of combination of hashing package.json, yarn.lock, .neutrinorc.js, and any other used middleware, stored in a dot file in cwd.

[edmorley]

I guess one complication is that if we only hashed .neutrinorc.js, it wouldn't cover local files imported therein.

In addition to more Neutrino-specific caching, I guess it might be worth looking into v8-compile-cache. Initial testing locally (ie adding it to the main neutrino package.json and then adding require('v8-compile-cache'); to the top of packages/neutrino/bin/neutrino), sped up time packages/neutrino/bin/neutrino lint --inspect for this repo from 1.75s to 1.44s. Not much, but a start.

We may also want to do some profiling to see if we can fix any underlying slowness, which depending on wins might mean we don't need Neutrino-specific caching (this would help speed up the cold run cases too).

[eliperelman]

Didn't even know about the compile cache package, that's pretty neat.

[eliperelman]

https://www.nearform.com/blog/introducing-node-clinic-a-performance-toolkit-for-node-js-developers/

[edmorley]

So I've been digging into this a bit.

For Treeherder's WIP Neutrino 9 .neutrinorc.js (which uses @neutrinojs/airbnb, @neutrinojs/react, @neutrinojs/copy and a custom (neutrino) =>{} block), running ESLint pointing at the Neutrino-generated .eslintrc.js took 2400ms longer than if the .eslintrc.js was converted to a fixed object export containing the same options.

This is pretty awful, and something we really need to fix.

I tried v8-compile-cache (which ESLint's CLI doesn't already use, unlike webpack-cli), and that reduces the time by 300-350ms, which is a start but still a long way to go.

I then used time-require, which showed that virtually all of the time is taken up with the many require()s - and in the case of the .eslintrc() output handler most of the imported files aren't even used (for example the webpack plugins). Just to emphasis the difference this makes, after commenting out all presets but @neutrinojs/airbnb, the overhead dropped from 2400ms to 250ms.

As such, I think a big win would be to lazy-require the plugins, that way for use-cases that don't generate a full webpack config (eg linting, jest, mocha) no time is wasted importing the plugins, and even for cases where a webpack config is generated, we would avoid require()ing plugins that were not applicable to that environment (eg we'd skip the require of clean/mini-css-extract/... plugins in development).

To achieve this, I was thinking we could modify webpack-chain, so that if the plugin was passed as a string, then webpack-chain would require() it during the .toConfig(). Then the Neutrino presets would just pass the string from require.resolve(...). Though not sure how this would work for the plugins that aren't the default export (eg const { EnvironmentPlugin } = require('webpack')) - other than perhaps just requiring the plugin directly (eg require.resolve('webpack/lib/EnvironmentPlugin')).

@eliperelman - thoughts?

[edmorley]

I guess this is another case where the inability of middleware to know what command is being run (since middleware accumulation occurs before calling the output handler) limits what we can do. If we were starting from scratch, it would seem that perhaps the middleware API would allow presets to have multiple phases/events, so accumulation, registering commands and actual execution were all separate (and sometimes optional) steps.

[eliperelman]

@edmorley we could support the string require use case, and worst case scenario, a plugin could be defined that did:

plugin('alpha')
  .use((...args) => new require('alpha')(...args), [1, 2, 3])

[edmorley]

To achieve this, I was thinking we could modify webpack-chain, so that if the plugin was passed as a string, then webpack-chain would require() it during the .toConfig()

I've opened neutrinojs/webpack-chain#102

[eliperelman]

Should we consider this fixed now?

[edmorley]

Yeah config generation is now 5x faster for the eslintrc case, and further improvements would mean more invasive changes.