In the first part of this article we took stock of Gulp's job as part of our front-end build process, in order to replace it with webpack which is better suited for the js module system and code-on-demand approach rather than just one single project albeit optimized package.
What is webpack?
webpack is a module bundler, that takes modules with dependencies and generates static assets.
If the above paragraph felt like visibility/accessibility modifiers to you, it's ok to feel that way.
Webpack approaches every static asset as a module and looks out for their dependencies and loads them as needed depending on an entry point's dependencies. This provides a big performance boost for large projects that can have multiple dependencies.
Setting up our webpack project
Our webpack project setup is similar to our Gulp project. A
src/ directory with our development assets and a
dist/directory for the buid output.
You can clone the Github repo here.
cd into the
webpack-build directory and run
yarn to setup the tools we'll be using for the webpack build.
Like Gulp's configuration file,
gulpfile.js, webpack uses a configuration file,
webpack.config.js to manage its build process. At the very basic-level a webpack config file consists of entry-point(s) files and corresponding output(s) files. An entry point represents a module and the dependencies specified in the code are processed and bundled to the output.
To build your webpack bundle with this basic configuration all you need is to run
webpack from the command-line
and webpack will output the processed file in the path specified in the config file's output property.
We have a number of non-JS resources in our project such as css, and sass. Let's see how all these come together.
Rebuilding our project with webpack
For our build, we'll be requiring a number of modules from our entry file
Luckily, in the first part of this post we took stock of the job description for our front-end build, It comes in handy as we upgrade our basic webpack configuration to handle the entire project.
Based on the job description, we can now upgrade our webpack config file as follows:
Matching the job description in the table with the upgraded file makes it easy to follow what is happening in the webpack config file.
Now you are ready to build with this new configuration and take your project live. Our build command will be a little different, as we want webpack to optimize our files for production. Running webpack with a little modification ensures we get all the optimisation goodness
That should do it. From the results, we have successly replaced Gulp with webpack and our build works perfectly with all the optmisation benefits.
We have only touched the surface in this post as webpack can do a lot more. This is a good thing but it has many times made it difficult for beginners to jump into webpack as many resources move from simple stuff to advanced stuff without closing the gap. Remember you can clone the Github repo here.
If you are new to webpack, take some time to see webpack from first principles.
When you want to start your project, you'll always find it helpful to list the jobs you want done by webpack, like in the table above and then pair that with the configuration, modules, and loaders you need to make that happen.