Learn webpack

The sample chapter

By Jakob Lind
[Link]

In this sample chapter, you’ll first learn how to create two webpack config files - one for dev and
one for prod. Then you will continue to learn how to create two different bundles - one for admin
and one for the public facing site.

To be able to follow this you must have an existing project to start from. You can download a
minimalistic webpack project on ​[Link]

The full book can be purchased on ​[Link]

Enjoy!
Separate prod and dev configs
A simple webpack config for a React app looks something like this as you already
learned:

const​ webpack = ​require​(​'webpack'​);

​ equire​(​'path'​);
const​ path = r

const​ config = {
entry: ​'./src/[Link]'​,
output: {
path: [Link](__dirname, ​'dist'​),
filename: ​'[Link]'
},
module: {
rules: [
{
test: ​/\.(js|jsx)$/​,
use: ​'babel-loader'​,
exclude: ​/node_modules/
}
]
},
resolve: {
extensions: [
​'.js'​,
​'.jsx'
]
}
}

module​.exports = config;

And you have scripts in ​[Link]​ to start it and build it:

​"scripts"​: {

1
 ​"build-dev"​: ​"webpack -d --mode development"​,
​"build-prod"​: ​"webpack -p --mode production"
},

If this doesn’t look familiar, take a look at ​Part 1​ of the book again.

Now, the problem with this is that there is only one webpack config for both production
and development. That means if you add some extra optimizations meant for production
in the webpack config, you will also get those optimizations in your development build.

What you want to do is to have ​separate​ webpack configs for development and
production.

If we look at the docs for webpack-cli (​[Link] you can see that it
accepts an input parameter called ​--config​. Here you can specify which config file to
use when you build. You can use this parameter in the ​[Link]​ file where you
specify how to call the webpack cli:

​"scripts"​: {
​"build-dev"​: ​"webpack -d --mode development --config
[Link]"​,
​"build-prod"​: ​"webpack -p --mode production --config
[Link]"
},

Note that you now use two separate webpack configs: ​[Link]​ and
[Link]​. Now you just need to create these files. Let’s just do that by
copying the old ​[Link]​:

cp [Link] [Link]
mv [Link] [Link]

Now you have separate configs for prod and dev. You can add hot reloading to the dev
config and optimizations to the prod config.

2
But there is one problem.

There will be lots of duplicate code in these two config files.

Most of the dev config and the prod config will contain the same stuff. Things like the
entry​ and the ​loaders​ will be the same in prod and dev.

Let’s improve this.

Remove duplicated code with webpack-merge

To remove the duplicated code in the webpack configs, we’ll create a base webpack
config that’ll contain the things that dev and prod have in common. Then we will extend
from this base config when we create the dev config and the prod config.

There is an awesome library that is called ​webpack-merge​ that helps us merge two
webpack configs. We will use this library to merge the base config with the prod config
and the dev config.

Let’s start by installing ​webpack-merge​ as a dev dependency:

npm install --save-dev webpack-merge

And then we will create the ​[Link]​ which look exactly like our old
[Link]​:

const​ webpack = ​require​(​'webpack'​);

​ equire​(​'path'​);
const​ path = r

const​ config = {
entry: ​'./src/[Link]'​,
output: {
path: [Link](__dirname, ​'dist'​),
filename: ​'[Link]'

3
 },
module: {
rules: [
{
test: ​/\.(js|jsx)$/​,
use: ​'babel-loader'​,
exclude: ​/node_modules/
}
]
},
resolve: {
extensions: [
​'.js'​,
​'.jsx'
]
}
}

module​.exports = config;

Now let’s extend from the base config in the ​[Link]​ file

const​ merge = ​require​(​'webpack-merge'​);

const​ base = ​require​(​'./[Link]'​);

const​ config = {
devServer: {
contentBase: ​'./dist'
}
}

module​.exports = merge(base, config);

This dev config will add the ​devServer​ section to the base config. You will learn more
about ​devServer​ in the next chapter where you’ll create an awesome dev experience.

4
Note how we use the function ​merge​ from the library ​webpack-merge​ to merge the base
config that we just created and the new dev config. The ​merge​ function creates a config
that looks like this:

{
entry: ​'./src/[Link]'​,
output: {
path: [Link](__dirname, ​'dist'​),
filename: ​'[Link]'
},
module: {
rules: [
{
test: ​/\.(js|jsx)$/​,
use: ​'babel-loader'​,
exclude: ​/node_modules/
}
]
},
resolve: {
extensions: [
​'.js'​,
​'.jsx'
]
},
devServer: {
contentBase: ​'./dist'
}
}

Next, we will create the webpack prod config in a similar way.

This is how ​[Link]​ looks like:

const​ merge = ​require​(​'webpack-merge'​);
const​ base = ​require​(​'./[Link]'​);

5
 const​ config = {
optimization: {
splitChunks: {
chunks: 'all'
}
}
}

module​.exports = merge(base, config);

This prod config uses the ​optimization​ config item that will extract the dependencies
to its own bundle to improve caching. You will learn more about this in the caching
chapter

Again we use ​merge​ function to merge the ​[Link]​ with the prod
webpack config. The merge function creates a config that will look like this:

{
entry: ​'./src/[Link]'​,
output: {
path: [Link](__dirname, ​'dist'​),
filename: ​'[Link]'
},
module: {
rules: [
{
test: ​/\.(js|jsx)$/​,
use: ​'babel-loader'​,
exclude: ​/node_modules/
}
]
},
resolve: {
extensions: [
​'.js'​,
​'.jsx'

6
 ]
},
optimization: {
splitChunks: {
chunks: 'all'
}
}
}

That’s it. Now we have DRYed up the code. You can build the prod bundle and dev
bundle just like before:

npm run build-dev

npm run build-prod

And they will use different webpack configs!

More than one output

You have seen how you can create two webpack config files - one for prod and one for
dev - by using a common config file.

There are more use cases where it is useful to create two configs. That is when you
want two different outputs - that means creating two different bundles.

One use case for this is if your app has two distinctly different parts. It could be that one
part is the public part and the other is the admin. You don’t want the code for the admin
part to be visible in the public bundle because that would be a security vulnerability.

Another example is if you want to implement SSR (server-side rendering). Then you
want to run the client side code ​and​ the backend code through webpack. That means
you want two outputs.

We will look more into both of these cases.

7
How to make two bundles - public and admin
Let’s start looking at the case where you have two distinct parts of your website. The
authorized user might see the admin part of the app and everyone else can see only the
public facing site.

We start by creating the ​[Link]​ file that both our webpack configs
will merge with:

const​ webpack = ​require​(​'webpack'​);

​ equire​(​'path'​);
const​ path = r

const​ config = {
module: {
rules: [
{
test: ​/\.(js|jsx)$/​,
use: ​'babel-loader'​,
exclude: ​/node_modules/
}
]
},
resolve: {
extensions: [
​'.js'​,
​'.jsx'
]
}
}

module​.exports = config;

Note that we don’t specify the entry or the output because we will do that in the other
config files. Now let’s extend from the base config in the ​[Link]
file:

8
 const​ merge = ​require​(​'webpack-merge'​);
const​ base = ​require​(​'./[Link]'​);

const​ config = {
entry: ​'./src/[Link]'​,
output: {
path: [Link](__dirname, ​'dist'​),
filename: ​'[Link]'
},
}

module​.exports = merge(base, config);

And in a similar way we extend the base config in the ​[Link]​:

const​ merge = ​require​(​'webpack-merge'​);

const​ base = ​require​(​'./[Link]'​);

const​ config = {
entry: ​'./src/[Link]'​,
output: {
path: [Link](__dirname, ​'dist'​),
filename: ​'[Link]'
},
}

module​.exports = merge(base, config);

Alright, now we have all the configs we need.

To build this you need to run webpack twice: once for the public bundle and once for the
admin bundle. Let’s create a script in ​[Link]​ that does this for us:

​"scripts"​: {
​"build-public"​: ​"webpack -d --mode production --config
[Link]"​,

9
 ​ build-admin"​: ​"webpack -p --mode production --config
"
[Link]",
​"build"​: ​"npm run build-public; npm run-build-admin"
},

If you now run ​npm run build​ it will run both ​build-public​ and ​build-admin​ which
will create two bundles for you.

But the full book to continue reading

More information at ​[Link]

10