Brown Bag: Webpack
What is webpack:
Webpack is a javascript module bundler (if you can remember from design patterns, modules in javascript are self-contained sections, allowing them to be shuffled, removed, or added as necessary, making it easier to maintain and reusable). Webpack takes in all these modules and files and generates it into one single file that runs your app, or depending on configuration like Chuffeds, it can produce a number of different files.
Out of the box webpack also watches for changes and reruns the build, and any other tasks that we configure. It also runs a development server, meaning we can run “webpack” and it produces a development build of the files and serves it on localhost.
From webpack 4, webpack has allowed us to distinguish the builds between development and production. The differences between these are mostly that one compiles and minifies the code to make it faster to serve in the browser, and in development the minification step is skipped so we can easily debug in the browser.
Aside from what webpack offers out of the box (the processing of json and js files), webpack includes loaders. Loaders are additional node modules that help ‘load’ or ‘import’ other file types into browser acceptable formats like CSS, SVGs and so on.
Webpack also contains plugins, which are separate to loaders. Plugins are additional node modules that usually work on the bundled file/files/directory. Popular plugins include babel transpile, this plugin turns the latest features of javascript (es6) in our code into es5 code that older browsers can read, so worrying about browser support, although not a thing of the past, is much more reliable now. Other plugins can run post build cleanup, or uglifyJSPlugin takes the bundle.js and minimizes the contents to decrease the file size.
So in comparison, loaders work at the individual file level during or before the bundle is generated. Whereas plugins work at bundle or chunk level and usually work at the end of the bundling process. And some Plugins like commonsChunksPlugins go even further and modify how the bundles themselves are created.
Basic usage: How do you use it? So webpack in its simplest form looks for an input file, in most instances this is just index.js file on the root, and it will build whatever is in that file and or imported in there into an dist/output file. This can be configured to look for entry points with a different name, or sub-folders, but as of webpack 5, if you want webpack in its simplest form it requires no configuration.
Below is an example of what an input and output looks like in the configuration file. The output object has two keys, one is path, and the other is publicPath, path is what directory the bundled files live in. PublicPath is used by several Webpack’s plugins to update the URLs inside CSS, HTML files when generating production builds. For example, in your CSS, you may have a url to load ‘./test.png’ on your localhost. But in production, the ‘test.png’ might actually be located at a CDN. So that means, you’ll have to manually update the URLs in all the files to point to the CDN when running in Production. Instead, you can use Webpack’s publicPath and different plugins that are publicPath-aware to automatically update URLs when generating production builds.
Configuration can be easily manipulated and we can change where the bundling process begins from a user defined entry point or points in a webpack.config.js file. That output path value could be a string, array or an object. Passing an object as an entry point will produce multiple entry modules, and generate multiple files.This is how we create multiple js files in our configuration. Entry points themselves are modules, and as mentioned above these entry modules can point to other modules through imports.
An example of this would be in our react page component which is considered our entry, the import of the other components such as Input, TextHeader are considered other modules which have now been imported.
So what exactly happens? Behind the scenes when you bundle a project, webpack constructs a dependency graph of the project that contains all the necessary modules needed in the application and then packs them together in either one or a few small bundles to be loaded into the browser.
How does webpack do this? Webpack manages the build process using what’s called “chunks” and “chunks” are smaller pieces of code that are included in the bundles seen in the output.
So that brings me onto some basic and popular configuration of loaders and plugins that the majority of projects would be using.
Firstly, here is an example of configuring styles using loaders. In this example you can see there are multiple loaders for each rule, style-loader and css-loader being the two different ones. CSS-loader interprets the import tags in the JS files, e.g. import ‘./style.css’ and style-loader is then responsible for injecting the CSS into the DOM using the