Webpack’s Little Secret

And introducing auxpack

Webpack

Webpack is… a lot.

It’s incredibly robust, it does a ton for bundling our projects… it’s a lot. And because Webpack is a lot, it can be a daunting and potentially confusing part of building a project.

Before we get into what Webpack does and how we can make the most of it, let’s first quickly refresh on why we bundle projects in the first place.

Put simply, bundling our projects makes larger bases of modular code a possibility.

For instance, if we have a JavaScript file that calls upon a separate .js file to operate, we would need to insert each of these scripts into our HTML file in proper sequence for them to work.

Extrapolate this a bit to larger projects with dozens of scripts, or externally-written modules, and it’s easy to see why bundling becomes a necessity.

It is also necessary to transpile code written in frameworks ( and libraries ) such as React, Vue , or Angular, into plain JavaScript for the browser to read.

Enter Webpack. As we’ve covered, it does a lot. In the seemingly-infinite depths of Webpack, it manages a host of external tools to not only bundle modular code into a single script for our HTML, but to also transpile our React JSX (or other framework code, I’m not biased).

It’s a one-stop-shop for bundling and transpiling, among other useful tools such as uglify and minify that keep our bundle files as lightweight as possible.

That’s not to say it stands alone in its field; there are a few options when it comes to bundling projects, but with a staggering nine-million weekly downloads, Webpack is the clear frontrunner.

Its peers include Parcel at 28,000 weekly downloads, and Rollup at around one million. Note: these statistics are pulled from npm as I’m writing this article at the end of 2019.

It’s safe to say that Webpack is something of an industry standard, and that speaks to what it offers developers. It also happens to be routinely maintained and updated, ensuring consistent performance and tooling.

Sample webpack.config.js

So, Webpack is pretty great, what’s the point?…you may ask. Well, the average developer isn’t a Webpack expert. Trust me, I polled something like twenty peers before writing this.

Using Webpack requires an often-confusing webpack.config.js configuration file, and does all of its work under the hood. Why is this an issue?

Say you’ve bundled your project into a nicely transpiled, minified, uglified bundle.js file. How can you be sure it’s at its true optimized potential?

Maybe the file is heavy, maybe it took a bit of time to build, maybe there are things within your project that could be nixed. How is one to know where things could be improved?

Perhaps this isn’t vital information for a smaller dev who’s creating a simple SPA (single-page application), but perhaps it would be useful for larger projects, or for companies who want to save time running builds, or ensuring they’re deploying the most efficient version of a bundle.

Well, Webpack actually does provide this information, it’s just not extremely accessible. Fortunately, there are tools one can install to simply retrieve some of this build data.

Auxpack is a lightweight dashboard that can be easily npm-installed and placed into your webpack.config.js .

After this minimal configuration is in place, every time you run a build, the auxpack dashboard will pop up and display the more useful statistics harvested in the Webpack build process.

Although this may seem trivial to a smaller application, I would encourage even smaller developers to take a look at these statistics. It can be useful to monitor where the space of your build is being spent.

Dashboard aside, this hidden information that Webpack generates is yet another powerful asset that many developers aren’t aware of.

The depths of Webpack’s utility remain to be seen, but with a little extra light shone on these statistics, we can hopefully implement a more optimized, informed build process.

PS. auxpack is an open-source project, so anyone can check out the codebase and offer improvement pull requests.