I’ve adopt­ed a few con­ven­tions for the web­pack con­fig files webpack.common.js & webpack.prod.js to make things more consistent.

Each con­fig file has two inter­nal configs:

lega­cy­Con­fig — the con­fig that applies to the lega­cy ES 5 build

— the con­fig that applies to the lega­cy build mod­ern­Con­fig — the con­fig that applies to the mod­ern ES 2015 + build

We do it this way because we have sep­a­rate con­fig­u­ra­tions to cre­ate the lega­cy and mod­ern builds. This keeps them log­i­cal­ly sep­a­rate. The webpack.common.js also has a baseC­on­fig; this is pure­ly organizational.

Think of it like Object Ori­ent­ed Pro­gram­ming, where the var­i­ous con­figs inher­it from each oth­er, with the baseC­on­fig being the root object.



The webpack.dev.js con­fig does not have a con­cept of lega­cy & mod­ern builds; if we’re work­ing in local dev with webpack-dev-server , we can assume a mod­ern build.

Anoth­er con­ven­tion that I’ve adopt­ed to keep the con­fig­u­ra­tion clean and read­able is to have configure() func­tions for the var­i­ous web­pack plu­g­ins and oth­er pieces of web­pack that need con­fig­ur­ing, rather than putting it all inline.

I did this because some data com­ing from the webpack.settings.js needs to be trans­formed before it can be used by web­pack, and because of the dual legacy/​modern builds, we need to return a dif­fer­ent con­fig depend­ing on the type of build.

It also makes the con­fig files a bit more read­able as well.

As a gen­er­al web­pack con­cept, under­stand that web­pack itself knows only how to load JavaScript and JSON. To load any­thing else, we need to to use a loader. We’ll be using a num­ber of dif­fer­ent load­ers in our web­pack config.

