This index lists common terms used throughout the webpack ecosystem.

A

• Asset: This is a general term for the images, fonts, media, and any other kind of files that are typically used in websites and other applications. These typically end up as individual files within theoutput but can also be inlined via things like thestyle-loader orurl-loader.

B

• Bundle: Produced from a number of distinct modules, bundles contain the final versions of source files that have already undergone the loading and compilation process.
• Bundle Splitting: This process offers one way of optimizing a build, allowing webpack to generate multiple bundles for a single application. As a result, each bundle can be isolated from changes effecting others, reducing the amount of code that needs to be republished and therefore re-downloaded by the client and taking advantage of browser caching.

C

• Chunk: This webpack-specific term is used internally to manage the bundling process. Bundles are composed out of chunks, of which there are several types (e.g. entry and child). Typically,chunks directly correspond with the outputbundles however, there are some configurations that don't yield a one-to-one relationship.
• Code Splitting: Refers to dividing your code into various bundles/chunks which you can then load on demand instead of loading a single bundle containing everything.
• Configuration: webpack configuration file is a plain old JavaScript file that exports an object. This object is then processed by webpack based upon its defined properties.

D

• Dependency Graph: Any time one file depends on another, webpack treats this as adependency. Starting from an entry point(s), webpack recursively builds a dependency graph that includes every module/asset your application needs.

E

• Entry Point: The entry point tells webpack where to start and follows the graph of dependencies to know what to bundle. You can think of your application's entry point(s) as thecontextual root(s) of what you want bundled.

H

• Hot Module Replacement (HMR): A process that exchanges, adds, or removesmodules while an application is running without a full page reload.

L

• Loaders: Transformations that are applied on the source code of a module. They allow you to pre-process files as yourequire() or "load" them. Similar to a 'task-runner'.
• Lazy Loading: A process of loading parts (chunks) of your application lazily. In other words loading them only when we really need them.

M

• Module: Discrete chunks of functionality that provide a smaller surface area than a full program. Well-written modules provide solid abstractions and encapsulation boundaries which make up a coherent design and clear purpose.
• Module Resolution: A module can be required as a dependency from another module and a resolver is a library which helps in locating a module by its absolute path. Modules are searched for inside all directories specified inresolve.modules.
• Manifest: The runtime will use it to resolve and load modules once they've been bundled and shipped to the browser.

O

• Output: Option(s) specifying where to output the compiled files to disk.

  Note, that while there can be multiple entry points, only one output configuration is specified.

P

• Plugin: A JavaScript object that has anapply property. Thisapply property is called by the webpack compiler, giving access to the entire compilation lifecycle. These packages will typically extend compilation functionality in one way or another.

R

• Request: Refers to the expression in the require/import statement, e.g.require("./template/" + name + ".ejs"), the request is"./template/" + name + ".ejs".

S

• Shimming: Not all JS files can be used directly with webpack. The file maybe in an unsupported module format, or not even in any module format. It is here whereshimming comes into play.

T

• Target: User configured deployment target(s)listed here to compile for a specific environment like the browser, NodeJS, or Electron.
• Tree Shaking: Unused/Excess code elimination, or more precisely, live code importing. Compilers like webpack will accomplish this by analyzing the various kindsimport statements and usage of the imported code to determine what parts of dependencies are actually being utilized, dropping parts of the "tree" that are not.

V

• Vendor Entry Point: Create dependency graphs starting at bothapp.js andvendors.js. These graphs are completely separate and independent of each other to allow leverage ofCommonsChunkPlugin and extract any vendor references from your app bundle into your vendor bundle. Helps achieve a common pattern in webpack known aslong-term vendor-caching.

W

• webpack: A highly configurablemodule bundler for modern JavaScript applications.

7 Contributors