@rspack/core), and lets you extend the generated config directly.
How it works
Create one of these files at project root:extension.config.jsextension.config.mjsextension.config.cjs
config key to patch generated bundler config.
config capabilities
| Capability | What it does |
|---|---|
Function hook (config: (config) => config) | Gives full control to read and modify generated Rspack config before build. |
Object merge (config: { ... }) | Merges additional config into the generated base config. |
Rules (config.module.rules) | Adds or changes loader rules for file types. |
Plugins (config.plugins) | Adds compile-time plugins and transformations. |
Resolve (config.resolve) | Adds aliases and module resolution behavior. |
Option 1: function hook (recommended)
Option 2: object merge
config can also be an object. Extension.js merges it into the base config.
Rspack-first, webpack-compatible
Extension.js is Rspack-native, but you can still use much of the webpack ecosystem.- The config type extends
@rspack/coreConfiguration. - Many webpack loaders/plugins work through compatibility layers.
- Some webpack internals/plugins are not 1:1 compatible with Rspack.
When to use this
- Add custom loaders/rules for project-specific file types.
- Add plugins for compile-time transforms and diagnostics.
- Override resolve aliases and module behavior not exposed by first-class Extension.js options.
Best practices
- Prefer first-class options first: Use
browser/commandsconfig keys before low-level bundler overrides. - Patch minimally: Change only the pieces you need, then return the config.
- Keep plugins Rspack-aware: Prefer Rspack-native plugins when available.
- Verify on all targets: Test
dev,start,preview, andbuildfor your browser matrix after config changes.
Next steps
- Learn more about extension config (
extension.config.js). - Learn more about multi-platform builds.

