Webpack

Historical note: Webpack predates the practical availability of ESM modules by a decade from a time when combining many files into one large "bundle" helped optimize load times for Javascript (this is no longer the case with http/2). However, webpack is one of those ubiquitous tools you are still likely to come across in 2023, and knowing how it works is helpful if you are new to web development.

What It Does

There are several basic requirements that Webpack is used to resolve:

1. Adding extended javascript keywords related to modular development such as import or require. Without this, loading modules in-order would be the responsibility of the programmer, as Javascript is not a compiled and linked language like C++. Webpack actually parses your Javascript file, looks for these additional webpack-specific keywords, and REWRITES your code by inlining any referenced files.

2. As websites also have many static assets like images, webpack also provides ways to gather non-code resources from various places in a project directory to build the final uploadable website with its own directory structure for deployment to a web server. This can be different from the project directory source.

3. Webpack can also by used to transform one kind of file to another that can be used in a browser. For example, an extended CSS language like SASS is not usable by a browser until it is converted to plain CSS. Webpack plugins are written to handle cases like this, and there are a lot of them.

Webpack's only implements (1), with all other capabilities handled by plugins written by the community. Plugins use the Compiler API to hook-into Webpack's lifecycle of reading and writing files into bundles. Because of the multiple authors, configuration tends to be idiosyncratic as each plugin author uses a different approach to parameter naming; their model is often not clear until you read the actual source code. This lack of consistency is a general problem with any plugin-based open source tool that you have to be prepared for. Webpack also has had an unruly development path with many options being renamed or superceded. Other module bundlers (e.g. Parcel, Rollup) are responses to this chaos.

Webpack by itself is not a task runner like Grunt, so it's often invoked through as an npm script in package.json with syntax like webpack build [options], where options define (a) the entry file to start scanning (processing any require or import statements) and (b) the output where to put the combined bundle files. In practice, a config file is defined and passed on the command line as such: webpack --config webpack.config.js containing (at minimum):

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: __dirname+'/dist'
  }
};

This just tells Webpack to scan the program files and combine them into a single main.js file in a directory named dist. The real power of Webpack is its ability to transform other filetypes (e.g. scss) and add additional information (e.g. source maps) through plugins.

Because Webpack can be used to do so many things, it's common to have multiple configuration files for different use cases in the same project.

In Summary

• Webpack reads from an "entry point" javascript file and sucks down any files referenced in it in a recursive manner.
• Webpack combines all the files into a single "bundle" javascript file that can be loaded with a single <script src='bundle.js'></script> line in your HTML page.
• Webpack makes use a "plugin system" to processing of non-js files into a deployment-friendly form.
• While the plugin ecosystem is extremely rich, the sheer number of them lead to complicated configurations that are often poorly understood.