#Glossary

Below are some common terms used with Rspack and webpack.

#asset

An asset is a resource that is used in your application, such as images, fonts, videos, etc. They typically end up as files in your output directory which may need further processing such as being transformed into base64 string and inlined in the output bundle.

#asset module

An "asset module" is a special module type used to process static assets, such as pictures, fonts, videos, etc.

• Asset modules

#async chunk

An async chunk refers to a chunk that is loaded asynchronously. When you use dynamic imports, Rspack will bundle the module into an async chunk.

#bundle

Historically bundlers produced a single output file called a "bundle." The concept of chunks was introduced later as part of a feature for automatically decomposing bundles into smaller files that can be loaded on demand.

#bundle splitting

Bundle splitting is a technique that allows you to split or merge your code into multiple bundles, which is useful for parallel request and better browser caching, it's not used for reducing the initialize bundle size.

• Code splitting

#built-in module type

In Rspack, built-in module types refer to module types that can be supported without relying on loaders or plugins, such as JavaScript, CSS, JSON, Assets, etc. However, module types that require loaders or plugins to support, such as TypeScript, HTML, Markdown, YAML, etc., are not built-in module types.

• Asset modules
• CSS
• JSON
• rules[].type

#cache group

A cache group is a set of rules for selecting modules and deciding how to split them, configured through cacheGroups. For example, you can select modules from node_modules and set a size threshold for splitting them.

Suppose two pages loaded on demand both depend on shared.js. A cache group can select this shared module. When the splitting conditions are met, SplitChunksPlugin can extract it into a shared chunk:

Before splitting:
Page A chunk: [page-a.js, shared.js]
Page B chunk: [page-b.js, shared.js]

After splitting:
Page A chunk: [page-a.js] ─┐
                         ├→ Shared chunk: [shared.js]
Page B chunk: [page-b.js] ─┘

Here, shared.js is the module, the shared chunk containing it is the splitting result, and the cache group provides the splitting rules. One cache group can produce multiple chunks; see the cacheGroups examples.

#chunk

A chunk groups modules during a build and produces corresponding output assets. For example, a page's code and the components it uses can belong to the same chunk.

Chunks can be classified by when they are loaded:

• Initial chunk: A chunk needed when an entry starts.
• Async chunk: A chunk loaded on demand during execution, such as one generated for a module dynamically imported with import().

#chunk graph

Chunk graph is a data structure that represents the relationship between chunks. It is a directed graph, and each node in the graph represents a chunk, and each edge represents the dependency relationship between chunks.

#code splitting

Code splitting is a technique that allows you to split your code into multiple chunks, and only load the necessary chunks when the application is running. This can help you reduce the size of the initial bundle and speed up the application load time.

• Code splitting

#context module

A context module represents a set of modules that can be loaded through a dynamic request. Rspack creates one for expressions such as import('./locales/' + name + '.js') and for require.context(). It defines which directory to search, whether to search subdirectories, and which relative requests are available.

#dependency

A dependency records an import relationship discovered while parsing a module’s transformed source. Rspack uses these relationships to build the module graph. During code generation, dependencies can generate import and export code, replace source code, and specify Rspack runtime requirements.

#initial chunk

Initial chunk is a chunk that is loaded synchronously, including the entry module of the page and the modules imported statically.

#loader

In bundling terminology, a loader is like a plugin but specifically tasked with transforming module content. For example, we can use a loader to transform a TypeScript module into a JavaScript module, or to transform a CSS module into a JavaScript module that injects the CSS into the page.

• Loader

#module

A module is a unit of code or a resource processed by Rspack, such as page.js, Button.tsx, or style.css. An application typically consists of multiple modules.

#module type

A module's type determines how it will be parsed and handled by the bundler. For example, we can tell Rspack that the module is a JavaScript module by specifying the module type as JavaScript, and Rspack will use the JavaScript parser to parse the module. If the specified module type is CSS, then Rspack will use a CSS parser to parse the module.

• rules[].type

#module specifier

A module specifier is a string that can be resolved to a path to the module file. For example, in the following code, ./modules/foo.js is a module specifier.

import { foo } from './modules/foo.js';

#module resolution

Module resolution is the process of calculating the file path indicated by a module specifier. For example, an import statement includes a module specifier, and Rspack will use the module resolution algorithm to find the corresponding file path.

• Module resolution

#module graph

module graph is also called dependency graph.

The module graph is a graph data structure that represents relationships between modules. It is a directed graph, where each node in the graph represents a module, and each edge represents the dependency relationship between modules.

#NAPI-RS

NAPI-RS is a framework for building pre-compiled Node.js addons in Rust. It simplifies the process of creating and publishing native Node.js addons by providing a high-level abstraction over the Node-API.

#plugin

A plugin is a program module that can be used to extend the functionality of Rspack by means of extensibility hooks. It can be used to customize the build process, or to integrate with other tools. Rspack provides lots of hooks which you can use to customize the build process.

• Plugin

#Rspack runtime

The Rspack runtime is the code Rspack includes in build output to load and execute modules, cache their exports, and load additional chunks. Depending on the configuration, it can also support features such as HMR. It runs within a JavaScript environment, such as a browser or Node.js; it is not the JavaScript engine or host environment itself.

• optimization.runtimeChunk

#Rspack runtime module

A Rspack runtime module (RuntimeModule) is a build-time unit that generates code for a specific part of the Rspack runtime, such as setting publicPath, loading chunks, or supporting HMR. Its generated code is included in the appropriate chunk. It is not an application module imported by your source code.

Plugins can extend RuntimeModule, implement generate() to return JavaScript code, and add an instance to a chunk with compilation.addRuntimeModule.

• runtimeRequirementInTree: Add runtime requirements or custom runtime modules.
• runtimeModule: Inspect or modify a runtime module's generated code.
• stats.runtimeModules: Display runtime modules in build statistics.

#scope hoisting

Scope hoisting is a technique that concat modules into a single scope when possible, rather than wrapping each module in a separate function. It can make minification more effective and improve runtime performance by reduce module lookup cost.

• optimization.concatenateModules

#tree shaking

Tree shaking is a technique that allows you to remove unused code from your bundle. It a form of compiler dead code elimination, with a focus on minimizing processing of dead code. Compilers like Rspack will accomplish this by analyzing the static structure of your code, and then removing the unused code.

• Tree shaking