icon picker

i was introduced to react through frameworks like gatsby and next.js, which provide many useful features for the resulting websites and for developer ergonomics, including abstracting away virtually anything to do with so-called “webpack configuration hell.” while this entry point allowed me to hit the ground running, it also let me go a long time not understanding what made the magic possible. i wanted to do some demystification, so these are some notes on the world’s leading static module bundler for modern javascript applications. it also turns out webpack’s docs are exceptionally well-written — genuinely a pleasure to learn from!

the why and the what

webpack turns the source files of a javascript project, containing multiple modules and other dependencies (images, css files), into a small number of static assets, called bundles, which can be served in browsers. modules are well-supported in server-side development (i.e. in nodejs), and webpack is designed to fulfill that need in browser environments.
from one or more entry points, webpack recursively figures out what the entry point module depends on (does it import or require anything? any image urls in css url(...) or in html <img src=...>?) and produces a dependency graph. then, it combines the necessary modules into (often just) one bundle, which the browser serves (e.g. loads in a <script> tag in an html page). fundamentally, “the bundling is a function that takes some files and emits others.”
to elaborate, the default entry point is ./src/index.js and outputs appear in ./dist/main.js (for the main file) and ./dist (for any other generated file). by default, webpack only understands javascript and json files, but loaders allow it to handle (”transform”) other types of files. webpack has built-in optimizations associated with different environments (”modes”), e.g. development and production, and plugins are available to provide other goodies: bundle optimization, asset management, injection of environment variables, and more.

extremely exciting features

code splitting

instance of concept of code on demand
code splitting “split[s] your code into various bundles which can then be loaded on demand or in parallel. It can be used to achieve smaller bundles and control resource load prioritization which, if used correctly, can have a major impact on load time.”
three approaches: entry points (easy and intuitive but manual), prevent duplication, dynamic imports
what about loading and transpiling at runtime?

hot module replacement

heard this term a ton, couldn’t define it but i could tell you some of the benefits i got from it and definitely missed it if i didn’t have it, compelling feature that i didn’t understand but that i tried to not take for granted despite it feeling ubiquitous :)
hot module replacement!!! (HMR) “exchanges, adds, or removes modules while an application is running, without a full reload... significantly speed[ing] up development” note that it is also only intended for use in development, not production.

under the hood

runtime and manifest

an application built with webpack gets injected with code called the runtime as well as a manifest. the runtime contains the logic needed to connect modules, e.g. connect loaded modules that are interacting, lazy-load ones that haven’t been loaded yet. it finds modules according to the manifest, which was previously generated by the compiler and has __webpack_require__ methods pointing to module identifiers.
manually bundling an application
live coding a simple module bundler
detailed explanation of a simple module bundler

using webpack

config file is not required, but it is very configurable and you would customize it to suit your needs in a file named webpack.config.js

webpack configs for create-react-app, next.js, and gatsby

come full circle and dig into how webpack is used in these familiar frameworks
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
) instead.