website/docs/en/config/target.mdx
import WebpackLicense from '@components/WebpackLicense';
<WebpackLicense from="https://webpack.js.org/configuration/target/" />The target option describes the environment in which the output code will run. Rspack uses it to determine which platform APIs and ECMAScript syntax the target environment supports, then sets compatible defaults for module resolution conditions, externals presets, and chunk loading. The runtime code generated by Rspack also uses syntax supported by the target environment.
When their own target options are omitted, Rspack's built-in loaders and minimizers can also inherit defaults from target. However, target does not add polyfills for missing APIs.
type Target = false | string | string[];
browserslist when the project includes a standard Browserslist configuration; otherwise webFor browser applications, define the supported browsers in a shared Browserslist configuration (see Browserslist for details):
{
"browserslist": ["fully supports es6"]
}
Use the following configuration:
export default {
target: 'browserslist',
};
When the project includes a standard Browserslist configuration, target defaults to browserslist, so the explicit option can be omitted. Keeping it explicit makes the intended runtime policy clearer.
If you do not use Browserslist and want browser output whose runtime uses at most ES2020 syntax, combine the platform and syntax targets (see Target arrays for details):
export default {
target: ['web', 'es2020'],
};
web selects the platform. es2020 limits the syntax used by the Rspack runtime; built-in transforms that inherit target also use it as their default output target.
For a Node.js application, specify the oldest Node.js version used in deployment:
export default {
target: 'node22',
};
Replace 22 with the version your application supports. A versioned target lets Rspack use runtime features known to be available in that release. An unversioned node target uses more conservative compatibility assumptions.
For code that runs in a Web Worker, Shared Worker, or Service Worker, use:
export default {
target: 'webworker',
};
This selects worker globals and chunk-loading behavior instead of browser APIs that depend on document.
In the patterns below, X and Y are version numbers, and brackets indicate optional parts. For example, node22, node22.12, and electron34-renderer are valid values; the brackets are not typed literally.
| Value | Use |
|---|---|
async-node[X[.Y]] | A Node.js environment that loads chunks asynchronously with fs and vm |
browserslist[:...] | Infer the platform and supported features from a Browserslist configuration, environment, or inline query |
electron[X[.Y]]-main | Electron main process |
electron[X[.Y]]-preload | Electron preload script |
electron[X[.Y]]-renderer | Electron renderer process |
esX | Limit ECMAScript features used by the runtime; normally combined with a platform target |
false | Disable target inference and target-derived defaults |
node[X[.Y]] | Node.js environment; chunks are loaded with require() |
node-webkit[X[.Y]] | Alias for the corresponding NW.js target |
nwjs[X[.Y]] | NW.js environment |
web | Browser-like environment |
webworker | Web Worker, Shared Worker, or Service Worker environment |
es3, es5, and es2015 through es2025.esX target describes syntax capabilities, not a runtime platform. It should usually be combined with a platform target such as web or node.Rspack derives several defaults from the selected target, including:
browser, node, and electronoutput.environment, chunk format, chunk loading, worker loading, and WebAssembly loadingdocument, require, global, and importScriptsThese are defaults. You can override the corresponding options when the target preset does not match a specific output requirement.
target directly controls the syntax that Rspack may use in its generated runtime. It does not, by itself, lower the syntax of every application module.
When used without an explicit transform target, the following built-in tools inherit a compatible default from target:
builtin:swc-loader derives env.targets or jsc.targetbuiltin:lightningcss-loader derives browser targets when availableSwcJsMinimizerRspackPlugin derives its ECMAScript targetLightningCssMinimizerRspackPlugin derives browser targets when availableOnly code processed by these tools receives their transformations. Code processed by Babel follows Babel's own configuration. Built-in tools may also limit inherited targets to the versions they support.
A target array applies the common subset of features supported by every item to a single compilation. A typical combination adds an ECMAScript constraint to a platform target:
export default {
target: ['web', 'es2018'],
};
A target array does not create a separate compilation for each environment. Combining conflicting platform targets such as ['web', 'node'] can leave defaults such as the chunk format indeterminate.
When you need separate browser and Node.js artifacts, export multiple configurations instead:
export default [
{
name: 'client',
entry: './src/client.js',
target: 'web',
output: {
filename: 'client.js',
},
},
{
name: 'server',
entry: './src/server.js',
target: 'node22',
output: {
filename: 'server.js',
},
},
];
Rspack runs these configurations through MultiCompiler and creates a separate compilation for each one.
The browserslist target uses a Browserslist query to infer both the platform and supported ECMAScript features. Browser queries select a web target, while Node.js queries select a Node.js target with matching runtime capabilities.
Rspack recognizes the following forms:
| Value | Resolution |
|---|---|
browserslist | Use the nearest configuration and its active environment |
browserslist:modern | Use the modern environment from the nearest configuration |
browserslist:last 2 versions | Use an inline query and ignore the project configuration |
browserslist:/path/to/config | Use an explicit configuration file |
browserslist:/path/to/config:modern | Use the modern environment from an explicit configuration file |
The nearest configuration can come from a browserslist or .browserslistrc file, or from the browserslist field in package.json. An explicitly selected browserslist target can also use the BROWSERSLIST environment variable. Rspack supports browser and Node.js queries; Electron queries are not supported.
Rspack 2.1.9 and later support Baseline queries. For example, the following target includes browsers that support every feature in Baseline Widely Available:
export default {
target: 'browserslist:baseline widely available',
};
You can also use a year query such as baseline 2024, or a fixed-date query such as baseline widely available on 2025-05-01. See Use Baseline with Browserslist for details.
Rspack uses browserslist-rs, which does not yet implement every Browserslist feature. The following queries are currently unsupported:
> 0.5% in my statscover 99.5% in my statsSet target to false only when you need to replace target inference with custom settings. This disables all target-derived defaults.
The following is a minimal configuration that uses the CommonJS chunk format:
export default {
target: false,
output: {
chunkFormat: 'commonjs',
},
};
A configuration containing only target: false will fail because Rspack cannot infer output.chunkFormat. Set output.chunkFormat explicitly, then configure other environment-dependent options, such as output.environment, chunk loading, resolution conditions, and externals presets, as needed.
output.environment overrides target-derived runtime syntax capabilities.output.chunkFormat and output.chunkLoading override how chunks are emitted and loaded.externalsPresets controls which platform built-ins are treated as external.resolve.conditionNames controls which conditions in the exports field of package.json are used during resolution.compiler.target.