I prefer to maintain a single file, webpack.config.js. This allows me to extract commonalities between different build targets to a common structure of its own. I manage composition through webpack-merge (disclaimer: I wrote it).

In the setup of my free book I pushed the level of abstraction so that I maintain higher level configuration at webpack.config.js and then compose it using webpack.parts.js functions. This becomes particularly useful as your configuration grows.

The repository contains other configuration files designed for particular demonstrations and you would most likely skip most of those in practice.

There's no single right way to manage webpack configuration. You have to find a way that suits your way of working. I prefer a composition based approach myself, but your mileage might vary.

Maria Olsen feel free to take a look at both configs in the below repository. I would also recommend Stephen Grider's Webpack 2 course on Udemy if you are wanting to learn that.

github.com/rockchalkwushock/photography-frontend/…

You can check out the webpack configuration files from mern-starter, they showcase a lot of bells and whistles.

I usually don't webpack my backend code, don't use CommonChunksPlugin (my apps usually have single entry point with many split points) and have a single config file (conditioned by environment variables) but the outcome is very similar.

I developed a solution for my own use, which in turn makes use of Juho Vepsäläinen's webpack-merge:

const builder = require('webpack-configify').default

const prod = process.env.NODE_ENV == 'production'

module.exports = builder()
    .production(prod)
    .development(!prod)
    .src('./src/index.js')
    .dest('./build', false)
    .loader('.js', 'babel-loader')
    .merge({output: {publicPath: '/build/'}})
    .build()

if (require.main === module)
    // eslint-disable-next-line no-console
    console.log(require('util').inspect(module.exports, null, null))