Webpack is a powerful tool for building modern JavaScript applications, but its architecture can be complex and daunting for developers who are new to it. In this talk, we will dive into the inner workings of Webpack and explore how its various components work together to create a bundle.
By the end of this talk, you will have a comprehensive understanding of Webpack's architecture and its plugin system. You will be equipped with the knowledge to build complex applications using Webpack confidently.
The Anatomy of Webpack: A Deep Dive Into Its Architecture
Video Summary and Transcription
Webpack is a module bundler that converts code into a format browsers can read. It has a plugin architecture built with Tappable that allows users to tap into hooks for important events. Tappable instances like compiler and compilation can be used to tap into hooks. The resolver in Webpack is used to check if required paths exist and can modify non-JavaScript files using loaders.
1. Introduction to Webpack
Hello everyone, welcome to my talk on the anatomy of Webpack. Webpack is a module bundler that allows you to write modules for the browser. It takes your code and converts it into a format that browsers can read. You can use Webpack via configuration, command line interface, or the Node API. Webpack starts with a configuration file, reads your entry files, and creates a dependency graph. It then applies loaders to transform the code.
Hello everyone, welcome to my talk, the anatomy of Webpack a deep dive into its architecture. So a little bit about me that I'm a front end engineer at Razorpay and I love open source. I've been involved in open source for almost three years and I've been helping in the maintenance and development of ESLint and Webpack ecosystems. I'm also a big fan of animes particularly One Piece and you can find me on internet as at snitin315.
So let's dive into our talk. So let's start with what is Webpack. So as we all know that Webpack is a module bundler. Another way of explaining Webpack is like it lets you write modules that works in the browser. So what does that mean is we write stuff that is nice for us to write and then Webpack takes all that code and converts into stuff that is nice for browsers to read. So what does that mean? So nice for you to write means easy for developers to read, can be separated into multiple files, multiple repositories. Might be in a language that browsers can't understand, ES6, TypeScript, etc. What would be nice for browsers to read would be ES5, frequent requests, smaller responses.
So how do we use Webpack? So you can use Webpack via configuration. You can define a configuration object with entry and output. And you can also use Webpack via its command line interface. You can just, on CLI, you can just pass Webpack, hyphen, hyphen entry, part to your entry file and then hyphen, hyphen output, hyphen file name, the file name of your bundle. You can also use Webpack server command which will spin up a local development server for you. Or you can directly use the Node API and you can just require Webpack from your Node modules and pass two arguments. First argument is the configuration objects, second is a callback.
So let's see the broad overview of how things work for Webpack over the hood. So we start with a Webpack configuration file. This is where you specify how Webpack should behave when it runs, including options such as entry points, output, directory, plugins, loaders, everything, optimizations, then Webpack read your entry files. And these are the files that Webpack uses to start building your dependency graph. Webpack will analyze the code in these files and follow any dependencies it finds to other files in your applications. Then it creates the dependency graph, which is nothing but just analyzes which module is mapped to another module. Relationships, basically relationships between each modules. Then it applies the loaders and transforms. So Webpack uses loaders to transform the code into each module. For example, there is a non-javascript file which you want to parse through Webpack. You will have to use a loader.
2. Webpack Plugin Architecture and Tappable
Webpack handles compiled output by creating a bundle file. Webpack's plugin architecture, built with Tappable, allows users to tap into hooks that notify and execute code for important events. Hooks can be created with Tappable by importing a sync hook and defining them in the constructor. Tapping into hooks is done using the tap method, with the plugin name and a callback function as arguments.
It could be a CSS file, it could be a PNG file. Then, when everything is compiled, it creates a compiled output. So, after Webpack has processed all the modules, it produces a single file which is called a bundle. And then, as per the output management, we configure how we want Webpack to handle this bundle file. Like where on disk we want to write this file.
So in Webpack, everything is a plugin. So what does that mean is more than 80% of Webpack's codebase is built of its own plugin architecture. But before we learn more about plugins, we need to know about Tappable. So what is Tappable? Tappable is a library that creates hooks for plugins. It is created and maintained by the Webpack team only. And it is the backbone of the Webpack plugin system.
So what are hooks? Hooks allow other users to get notified of important events and run the other user's code when any important event happens. For example, browser exposes many hooks for us to tap into. For example, this is a basic hook, document.addEventListener on click. So whenever a user clicks on the screen, a message is printed to the console. So similarly, Webpack exposes many hooks which you can tap into. And how do we create hooks with Tappable? So you can simply import a sync hook from Tappable and in the constructor of your class, you can define a This.hooks property in which you redefine all the hooks.
So how to create hooks with Tappable? Yeah, so that's how we create a hook. So for example, in this example, we have a class Car in which we have a constructor in where we have defined our hooks via This.hooks. We have two hooks one is CarStarted and radioChanged hook. So whenever we want to call this hook, we can just run its call method. For example, we have a turn on method where we can do This.hooks.carStarted.call and whenever we call the turn on hook, this CarStarted hook will be triggered. Yeah, but how do we tap into hook. So to tap into hook we run its tap method. So for example, in the earlier example, we initialized a new instance of myCar. Now we can do myCar.hooks.CarStarted.tap and the first argument is the name of the plugin and this name is used for debugging purposes. And the second argument is a callback function. This is called when your hook is called. So whenever you will do, you will run myCar.turnOn it will print CarStarted. Similarly you can also pass options to your plugins.
3. Webpack Tappable Instances and Plugins
In this part, we explore the tappable instances of Webpack, such as compiler and compilation. We learn how to tap into hooks like compilation.hooks.SEAL and compilation.hooks.optimized. Additionally, we look at an example of a basic plugin using the HelloCompilationPlugin class. The compiler is the top-level central dispatch for Webpack, while the compilation represents the dependency graph.
So in here you can see myCar.hooks.radioChange.tab a radio plugin and we have passed a radio station option and we are logging the radio change to the radio station. So if you call myCar.setRadioStation with 100.10 it will print radio change to 100.10.
So now let's learn more about the tappable instances of Webpack. So Webpack exposes many tappable instances. For example these are two of the tappable instances. One is compiler and one is compilation. So here the drawing is showing that to tap into the compilation hook we first need to tap into the compiler hook. So we do compiler.hooks.compilation.tap then compilation offers other hooks for us to use for example SEAL. So you will do compilation.hooks.SEAL.tap. These are the hooks which are used by plugins. So SEAL is used when all the compilation is done. Optimize is used for example when the optimization of assets is being started. And you can use just before the hashing is started in Webpack process.
So this is a basic example of a plugin. So we define a class HelloCompilationPlugin which accepts an apply method. Now which has access to the compiler object which with compiler you can access to compilation compiler.hooks.compilation.tab then again you have the plugin name and the callback accepts the compilation argument. Then via compilation, you can access the other hooks like optimize. Now we can type into various hooks available through compilation. So here we are tapping to optimize it compilation.hooks.optimized.tab hello compilation plugin and we are just logging assets are being optimized. So this is a overview of how a basic plugin looks like. So the first typeable instance is compiler. So it's the top level central dispatch for webpack. It basically starts and stop webpack processes and this is what we expose where the node API. So whenever you require a webpack, it gives you access to the compiler. So the first argument is a configuration object. The second argument is a callback. So whatever is returned by this function call is the compiler instance. Then comes the compilation. So compilation is created by compiler only and this is also known as the dependency graph. It's the brain of Webpack where Webpack kicks off building the graph, sealing it and rendering into bundles.
4. Webpack Compilation and Resolver
Inside the compilation object, Webpack uses the resolver to check if required paths exist. The resolver returns an object with details like path and context. If the file is non-JavaScript, Webpack checks for a loader in the configuration. If found, the CSS is passed through the loader and the modified state is returned.
Everything happens inside the compilation object. Then we have the resolver. So whenever we have required any path in the codebase, Webpack checks if that path actually exists or not. So the resolver takes care of the resolving. Here. So whenever we come across any import statement or a required statement, it goes through the resolver. It checks if the file actually exists and then return an object with some details related. Like path, context. And if it is a non-JavaScript file, for example, let's say foo.css. Then it will check your webpack configuration if you have defined a respective loader for the CSS extension. If not, it will throw an error. If there is a loader you have specified, it will pass the CSS through that loader and return the modified state.