Webpack for Beginners — Part 1

So what is Webpack? You may have come here because you are interested in exactly what webpack is. Or maybe you thought it was a delicious meal you wanted to try it out. Anyway, we will be learning Webpack from the ground up. Buckle your seat belts!

So this is what Wikipedia says about Webpack

Webpack is an open-source JavaScript module bundler. Webpack takes modules with dependencies and generates static assets representing those modules.

So what is all this? I’m wondering myself. It’s clear that Webpack has something to do with modules and bundling. But what is a module? It gets more difficult to appreciate without anything to show. Let start with HTML 101:

<script src="module1.js"></script>
<script src="module2.js"></script>
<script src="module3.js"></script>
<script src="module4.js"></script>

This is very common to any web developer. But something is wrong. The arrangements of the scripts matters. Also, it gets slow since the browser has to download all of the scripts. Whew!!

But then we upgraded into using something like Gulp, Grunt or other options like them. What’s their end? We then could do something like this:

// build-config.js
var scripts = [
  'module1.js',
  'module2.js',
  'module3.js',
  'module4.js'
].concat().minify().dest('build.js');
// referencing
<script src="build.js"></script>

That’s better because we only make a single call for the script and that’s faster than the previous implementation. But we still need to do something about the order in which we position the scripts in the build-config.js. Another bad thing is that code can only communicate through global variables. That’s weird since polluting the global namespace is a bad practice that leads to a lot of trouble you should be avoiding.

Webpack presents something cool — Dependency Graph. Today we have CommonJS and even ES6 modules. We only build for the things we actually need. See this:

// module1.js
module.exports = {
 sayHi: () => console.log('saying hi')
}
// module2.js
const { sayHi } = require('./module1.js');

In module1.js, we only said we want sayHi to be exposed to the outside (with module.exports object) and imported it into module2.js using destructuring. Where from the require() method? It seems it is the one that identified that we are exporting something in module1.js and knows how to pull it in. The browser doesn’t understand require() since it’s not a global value. Build tools understand it and know how to use it.

With Webpack, we can do something entirely different. It allows you to use require on any static asset. This can be applied to js files (like shown above), images (png, gif, whatever), stylesheets (css, sass, whatever).

// An example with images
<img src={require('../images/food.png')} />

Hmm. That’s getting more complicated. It is natural to think that Webpack works with JavaScript files but how can it work with png files? Webpack has loaders responsible for that.

module: {
  rules: {
    test: /\.png/,
    loader: 'file-loader'
  }
}

So what happens is that Webpack scans for require calls referencing assets with the file extension matching the test under rules. I’ll elaborate further on it in a later post.

From the little shown, it is very clear that at any time, some file depends on another or an asset. Webpack calls this dependency. Webpack is always provided an entry file either in command line or in a configuration file. From there, it builds a dependency graph that includes every module the application needs (whether code or non-code). It then packages them into small bundles (chunks) to be loaded by the browser.

One more thing. You may have heard of Webpack Dev Server. This is a small Express server that builds your assets according to your webpack configuration. It is meant for local development. It basically serves static files (something to keep in mind) on a port (can be changed) on your localhost.

Ok, we are done with explaining what Webpack is. What are the advantages of using it?

• You won’t deploy with assets missing. This brings some stability into our deployments.
• You have control on how your assets are processed.
• Hot module reloading and hot module replacement. (Will be discussed in an upcoming post)

What about the disadvantages? The bad side..

• Complex to set up.

So you now know what Webpack is. In the next post in this series, we’ll look into setting up Webpack.

Webpack for Beginners — Part 2