mutate-webpack-config.js

export function loadConfigModule(filename) {
  // sub your own
  return require(filename);
}

/**
 *  Modify a Webpack configuration by applying a mutator module/function.
 *  @param {Object} options
 *  @param {Object} options.config    Webpack configuration object to modify in-place
 *  @param {Object} options.module    A configuration function of the form `(config, env)=>`,
 *                                    or an Object with a `webpack` method of that form.
 *  @param {String} [options.target]      "client" for browser bundles, "server" for Node/SSR/prerendering
 *  @param {Boolean} [options.production] Defaults to `process.env.NODE_ENV==='production'`
 *  @param {Boolean} [options.watch]      Whether the bundle is being built for HMR/watch usage
 *  @param {Object} [options.env]         Environment values to expose as options to the config function
 *  @param {Object} [options.helpers]     Utility functions to pass as a 3rd arg to the config function
 *                                        Example: github.com/developit/preact-cli/blob/master/src/lib/webpack/transform-config.js#L29
 */
export function modifyConfig({
  config,
  module,
  target = 'client',
  production = process.env.NODE_ENV === 'production',
  watch = false,
  env = {},
  helpers = {}
}) {
  const webpackMutator = module.webpack || module;
  if (typeof webpackMutator !== 'function') {
    throw Error(`Webpack configuration plugin must be a function of the form (config, { target }) => void`);
  }
  
  const ssr = target === 'server';
  const options = {
    production,
    watch,
    target,
    ...env,
    // Compat aliasdes for Next.js, Preact CLI, etc
    ssr,
    isProd: production,
    isWatch: watch,
    isServer: ssr,
  };
  
  webpackMutator(config, options, helpers);
  
  return config;
}

@kentcdodds @timneutkens yup, same deal with Preact CLI (one for client, one for prerendering/ssr). Also there's the issue of nested configuration modifiers (~plugins).

Webpack Blocks had an interesting approach, which basically allowed merging multiple subsets of webpack configuration into their sum using logic that was aware of the config schema.

I've had that problem as well. I solved that by overloading the env argument:

// fullEnv could be any combination of:
// development:client
// production:server
// or even simply: "development" and it should still work
module.exports = (fullEnv) => {
  const [env, subenv = 'client'] = fullEnv.split(':')
}

It's a bit less straightforward 😬, but I thought it was worth it.

Also there's the issue of nested configuration modifiers (~plugins).

True, it's an annoying problem. Typically what I do is I filter out the plugins I want to change and add my own version of those plugins. But this is a problem regardless of what API you come up with.

What about having this feature in webpack itself? Like webpack.augmentConfig or something like that

Whether it's in webpack or not, webpack-merge seems like a good starting point.