This article will not explain how to use Webpack. Rather, explain the reasoning behind it, and what makes it more special than just a bundler.
Webpack is still a Bundler
Node.js allows you to modularise code. Modularisation of code causes an issue with dependencies. Cyclic dependencies can occur-e.g., A -> B -> A referencing. What tools like Webpack can do, is build an entire dependency graph of all of your referenced modules. With this graph, analysis can occur to help you alleviate the stress of such a dependency graph.
Webpack can take multiple entry points into your code, and spit out an output that has bundled your dependency graph into one or more files.
Webpack is so much more
For me, what makes webpack so special is the great extension points it provides.
The power of loaders is that they are not in short supply. Loaders are an extension point. You can create your own loader, and there are 100’s of default and 3rd party loaders out there.
The limits are boundless with loaders. Loaders can be chained, configured, filtered out based on file type, and more.
Custom Loader Example
As the webpack documentation explains, a loader is just a node module exporting a function. A loader is as simple as a defined node module that exports a function:
This is a trivial example of what a loader is. All this loader is doing is appending a function to write to the console on window load for the current browser session.
Plugins allow the customisation of Webpack on a more broader scope than file by file like loaders. Plugins are where you can add extra functionality to the core of Webpack. For example, you can add a plugin for minification; Extract certain text from output such as CSS; Use plugins for compression, and so on.
Plugins work by having access to the Webpack compiler itself. They have access to all the compilation steps that can and may occur, and can modify those steps. This means a plugin can modify what files get produced, what files to add as assets, ans so on.
A small example of a plugin is the following:
In this example, we are adding two event handlers to two separate event hooks in the Webpack compiler. The outcome of this is one date that is printed to console just before the assets are emitted to the output directory, and one date after the assets have been emitted.
This plugin can be used in the main Webpack configuration:
This plugin will now run on the emit and after-emit stages of the compilation process. A good list of compiler event hooks are available on the Webpack website.
The importance of plugins, once again, is that they are an extension point. The way Webpack has been designed is to allow the user to fully extend the core of Webpack. There are many plugins to choose from, and a lot are 3rd party.
With this in mind, a plugin could take all your assets that you require, and compress them with an algorithm. In fact, there is already a plugin for this very thing.
Webpack is a module bundler, that is what the label says. It takes your dependency graph, and outputs a browser readable format.
However, webpack can be so much more.
I think if you start thinking of Webpack as more of a transpiler, not just a bundler, the true power of Webpack can be seen.
Thanks for reading and hope this helps.