Skip to main content

Front-End Development

Webpack: It Configures part 1 – the Ins and Outs

Webpack Blog Meme

Webpack Configuration Files

Last time we talked about how to install webpack, what files are created and how we get webpack to do something. Configuration files are that “something.”

As described before, package.json lets us define which configuration files we want to use when running webpack. In package.json we need at least one build script defined. We’ll start with one called “common” for now as this will hold our core commands. Later we will make other scripts just for dev and prod which will then include anything “in common” in this script.

 "scripts": { 
     "common": "webpack --config webpack.common.config.js"

Next, create a file in the same folder as package.json called webpack.common.config.js.
Note: you can put it in any location and specify that path, but the same folder is easiest.

In the above “scripts” property we are creating a command which would be the same if we just typed it in the terminal, but instead are using an alias of “common” which makes it less verbose.  It first calls the module “webpack” that we installed before and tells it we have a –config file for you to digest.  Then we specify the name of the file assuming it is in the same folder as package.json.


Common Config File Properties

Now that we have our config file, let’s go over what kinds of things are in it and what they are for.

Top of the file

At the top we will have modules pulled in which the rest of the settings will require.
Below is a sample with a short description next to each already. It’s not important to know anything about these now, just know that at the top of the file you’ll either request a built-in node module or one you installed yourself.  Webpack’s official website has an extensive list of “plugins” as these modules are referred to there.

const path = require('path');                                       // absolute path evaluator
const MiniCssExtractPlugin = require('mini-css-extract-plugin');    // css extractor
const TerserPlugin = require('terser-webpack-plugin');              // minifier
const {CleanWebpackPlugin} = require('clean-webpack-plugin');       // dist folder file deletion on build 
const HtmlWebpackPlugin = require('html-webpack-plugin');           // html file generator

Looking at the above you’ll see that sometimes the const naming portion specifies just the name of the module or it might wrap it in braces { }. The difference is without braces it is referring to the whole file, while within braces it is targeting a certain class or function with that name in the file. Here, documentation for any plugin would be needed to find out how it should be used. It’s always a good idea when starting with plugin to read through all the options it may have even if you don’t need it right away.

The Configuration Object

This part can get very complex so we will start with a description of the kinds of things we will most likely want webpack to do as well as certain things we have to include.  If you are interested in an easy way to check out certain plugins and code structure it uses try

Here is a starting outline with a description of each part:

module.exports = {           //  the configuration object wrapper
     entry:{},               //  where we define the location for the index.js file (usually) to read 
     output: {},             //  where we define the filename(s) and location(s) for the final output
     mode: '',               //  what kind of build process should be used?
     module: {               //  general wrapper for how anything pulled into webpack should be processed
         rules: []           //  will contain specific instructions for each type of file we encounter
    plugins: []              //  will list all plugins and any options for each we want to run

entry settings

The simplest entry method is to give a single folder path to have webpack locate the index.js file. Multiple entry points can be listed.  Each should have a property name for it which can be referenced when desired.  You may also see this within brackets if multiple entries are needed for grouping per property.

entry: {
     default: './src'   // or specialgroup: ['./src','./otherfolder'] etc.

output settings

The output location requires some name to give it and where it should go.  This will be a javascript file. We also need to use our first imported module called path at the top of this file.

const path = require('path'); // absolute path evaluator

This will determine where we are by absolute path and is needed since once this goes into production, we’re not going to have the same file structure there.

Below we are going to call the output js file “bundle” and we want to use a folder called “dist” one level below our project folder, since that is where our config file resides.

  • path.resolve(…)  tells the module to figure out the absolute path we are in currently using.
  • __dirname  is a global variable provided by node.js which holds this folder’s absolute location.  Any module has access to global node.js variables, and webpack is a module like everything else.
  • ‘./dist/’ whatever final folder location the output files should be put in after the absolute path resolved
  • publicPath: ‘auto’ lets webpack determine the applicable root path for the browser to locate whatever file is included on whatever server we are building the project. This can also be set to a specific path if needed.
output: {
     filename: 'bundle.js',
     path: path.resolve(__dirname, './dist/'),
     publicPath: 'auto'


There are two modes: “production”, and “development.”  Setting the mode to “production” invokes certain default behavior in webpack to compress files and create files in the filesystem for serving to a client.  “development” tries to maximize speed during builds so when you are saving your work repeatedly you don’t have to wait as long.  This becomes much more important as your project gets bigger.

As described previously, we will eventually be splitting our configuration into two files with each set to a different mode. You won’t use “production” as much as “development”, and you don’t want to have to manually change this when it’s time to finalize the build for prod.

mode: 'development'

At this point we now have the basics for the type of build we going to do when running this config file, where webpack should begin looking for things to process and where to place the results.  We don’t have anything for it to do yet, but we now have to start to define some rules to follow when it does encounter files to process.

module.exports = {
     entry: { 
          default: './src'
     output: { 
          filename: 'bundle.js', 
          path: path.resolve(__dirname, './dist/'), 
          publicPath: 'auto'
     mode: 'development'

Next: It Configures part 2 – The Ruler’s Back

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ed Murphy

Ed Murphy is a Front End development veteran with over 20 years of experience. He’s constantly investigating the newest technologies available for the front-end developer and enjoys teaching others, as that’s the best way to teach yourself.

More from this Author

Follow Us