Configuring Webpack is quite easy but it may become more difficult if there are many environments and requirements. I’ve included Webpack in different projects recently and I would like to share with you an easy way to configure it. I’m sure there are many different ways to configure Webpack, maybe better, but I’m just going to compare two of them:

• One file to rule them all
• Extended configurations

One file to rule them all

When you start configuring Webpack your will be doing this. One configuration file to rule them all. This consists in having just a single file named for example webpack.config.js with everything written there together.

Something like this:

// Example file: webpack.config.js
const path = require(“path”);

module.exports = process.env.production ?
  getProdConfig() :
  getDevConfig();

/**
 * Creates webpack configuration for production.
 */
function getProdConfig() {
  return {
    entry: './foo.js',
    // Add your prod config here: Minify, remove logs, etc.
    output: {
      path: path.resolve(__dirname, 'dist'),
      filename: 'foo.bundle.js'
    }
  };
}

/**
 * Creates webpack configuration for development.
 */
function getDevConfig() {
  return {
    entry: './foo.js',
    // Add your dev config here (devserver, sourcemaps, etc.)
    output: {
      path: path.resolve(__dirname, 'dist'),
      filename: 'foo.bundle.js'
    }
  };
}

This is useful for small projects but your file will get bigger and bigger and one day you will see this structure is not legible nor maintainable. Before this day arrives I recommend you to split your configuration in different files like I explain below.

Extended configuration files

This structure is quite simple and adaptable. Start with just a file named webpack.base.config.js and extend it with your needs.

Here you have an example of a basic config:

const path = require(‘path’)

// This is the base configuration used on every environment
// It contains general information like entry point, output,
// common transformations, etc.
module.exports = {
  entry: './foo.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'foo.bundle.js'
  }
}

Let’s suppose you need to build a production version (minify, no source maps, no dev-server etc.). No problem. There is a package named webpack-merge that simplifies this situation. How is this? Easy, just create another file named webpack.prod.config.js and extend your base configuration using webpack-merge and overriding whatever you want. Let’s see an example:

const merge = require(“webpack-merge”);
const baseWebpackCfg = require(“./webpack.base.config”);

// We are using webpack-merge to extend the base configuration
// with specific information needed to build a version for
// production. We will add here minification, log removal, etc.
module.exports = merge(baseWebpackCfg, {
  plugins: [
    new MinifyPlugin()
  ]
})

Just one thing: Be careful when configuring a plugin because its properties are not going to be merged but overridden.

webpack-merge allows different options to merge your configuration files. I’ve used the easiest one but take a look to its website to find much more options to achieve your needs.

Conclusion

Using webpack-merge will make your webpack configuration files being organised, readable and maintainable but if your project is at its beginning, use just one file and adapt it in the future depending on your needs.