[Proposal] Consider composing webpack config

This is a continuation of this comment https://github.com/facebookincubator/create-react-app/pull/1651#issuecomment-305188047 and maybe related to https://github.com/facebookincubator/create-react-app/issues/670 (but for internal use only) and I want to see a discussion about this implementation.

For a past few months I’ve been working on PRs and watching this repo, and a lot of the PR and issues are about adding something to the webpack config. I thought to myself, how can we add something to it without making it more complex?

And then I read this articles reading https://medium.com/making-internets/webpack-configuration-done-right-86c325a6927f ,

I’ve been thinking maybe we should have an INTERNAL hook/middleware for composing webpack config.

Right now AFAIK we have 3 three separate PR working on adding something to webpack config, 2 of them is optional (DLL and commonsChunk) and one is CSS module (which the user can opt it out if they use CSS in JS solution).

And for the merged ones, SWPrecache is an optional feature but we still have the webpack plugins installed, even when the user is not using it.

I think we could go with something like

const compose = require('promise-compose');
const webpackAutoDllCompiler = options => config => new Promise(resolve =>
 if (dllSrcExists()){ // only modify the config if `src/index.dll.js` exists
  config.plugins = config.plugins.concat([new webpackDllCompiler(options)]) // simplified for example purpose
  //compile it
  webpack().run(() => resolve(config))
 }
 //don't waste resource on optional feature
 resolve(config)
)
const configComposer = compose(
  webpackAutoDllCompiler({
    dllConfig,
    paths,
  }), //config resolver for dll feature
  webpackPWAConfigResolver(), //config resolver for anything related to PWA feature
  webpackCSSModuleConfigResolver(), //config resolver for CSS Module
);


//somewhere in start.js
const config = require('barebone/config/without/additional/features')
webpack(configComposer(config))

The config resolvers could be placed in react-dev-utils or config/resolvers, so additional features are neatly placed in their own modules and called when needed.

I know maybe this would make the codebase harder to follow because the configuration is hidden in the resolvers, but it would make CRA more modular. if the ejected users wanted more config / disabling a feature, they can comment out the call in the configComposer and do the configuration themselves. This way trying out new features is just a matter of adding a new line in the compose function, and no resource wasted for unused features. And because it’s internal, we can control how the resolver plays with each other (plugin ordering issue, the shape of loaders section config etc). Thoughts?

[gaearon]

if the ejected users wanted more config / disabling a feature, they can comment out the call in the configComposer and do the configuration themselves

I don’t think this is an acceptable tradeoff. It’s hard enough to deal with Webpack configuration, and I feel like obscuring it behind a call will make it even harder for people who eject. For many users (especially new to JS), “call this function and inline the result” when they need to change something is pretty much insurmountable.

[gaearon]

Yes, pretty much that.