On this page

This index lists common terms used throughout the webpack ecosystem.

  • Asset: A general term for images, fonts, media, and any other kind of file that a website or application ships alongside its code. Assets usually end up as individual files in the output directory, but they can also be inlined into a bundle as a data URI.
  • Asset Module: The built-in module types (asset/resource, asset/inline, asset/source, and asset) that handle assets without a loader. They replace file-loader, url-loader, and raw-loader from webpack 4.
  • Bundle: Produced from a number of distinct modules, a bundle contains the final versions of source files that have already gone through the loading and compilation process.
  • Bundle Splitting: Splitting a build across several bundles so that a change to one part of the application does not invalidate all of the others. Each bundle can be cached by the browser independently, so fewer bytes need to be re-downloaded after a deploy.
  • Chunk: A webpack-specific term used internally to manage the bundling process. Bundles are composed of chunks, of which there are several kinds (such as entry and child chunks). Chunks usually correspond one-to-one with output bundles, but some configurations break that relationship.
  • Code Splitting: Dividing your code into several bundles or chunks that can be loaded on demand, instead of shipping a single bundle containing everything.
  • Compilation: The object that holds the state of a single build: every module, chunk, and asset, plus the hooks a plugin taps to influence them. A watch build creates a new compilation per rebuild.
  • Compiler: The long-lived object created from your configuration. It orchestrates compilations and exposes the top-level lifecycle hooks that plugins tap.
  • Configuration: A webpack configuration file is a plain JavaScript file that exports an object. webpack processes that object according to the properties defined on it.
  • Dependency Graph: Any time one file depends on another, webpack treats this as a dependency. Starting from one or more entry points, webpack recursively builds a dependency graph that includes every module and asset your application needs.
  • Entry Point: The entry point tells webpack where to start following the graph of dependencies to know what to bundle. Think of your application's entry points as the contextual roots of what you want bundled.
  • Hot Module Replacement (HMR): A process that exchanges, adds, or removes modules while an application is running, without a full page reload.
  • Lazy Loading: Loading parts (chunks) of your application only at the point where they are actually needed, rather than up front.
  • Loader: A transformation applied to the source of a module. Loaders let you pre-process files as you import or require them, similar to a task runner.
  • Manifest: The bookkeeping the webpack runtime uses to resolve and load modules once they have been bundled and shipped to the browser.
  • Module: A discrete chunk of functionality with a smaller surface area than a full program. Well-written modules provide solid abstractions and clear encapsulation boundaries.
  • Module Federation: A mechanism for one build to load code from another, separately deployed build at runtime, with shared dependencies resolved between them.
  • Module Resolution: The process of locating a module by its absolute path when it is required as a dependency from another module.
  • Output: The options that specify where webpack writes the compiled files, and under which names. There can be several entry points, but only one output configuration.
  • Plugin: A JavaScript object with an apply method. webpack calls apply with the compiler, giving the plugin access to the entire compilation lifecycle. Plugins typically extend what a build does in ways loaders cannot.
  • Public Path: The base URL the browser uses when requesting the files a build emits.
  • Request: The expression inside a require or import statement. In require('./template/' + name + '.ejs'), the request is './template/' + name + '.ejs'.
  • Runtime: The small amount of code webpack ships alongside your modules to connect them at run time: resolving module ids, loading chunks on demand, and wiring up hot updates.
  • Scope Hoisting: Concatenating modules into a single scope where it is safe to do so, instead of wrapping each one in its own function. It produces smaller, faster output and is enabled by default in production mode.
  • Shimming: Not every JavaScript file can be used directly with webpack. A file may be in an unsupported module format, or in no module format at all. Shimming bridges that gap.
  • Target: The deployment environment a build is compiled for, such as a browser, Node.js, or Electron.
  • Tree Shaking: Eliminating unused code, or more precisely, importing only live code. webpack accomplishes this by analyzing import statements and the usage of imported bindings to determine which parts of a dependency are actually reached, dropping the parts of the "tree" that are not.
  • webpack: A highly configurable module bundler for modern JavaScript applications.