the why and the what
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.”
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
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.