Output#

The top-level output key contains a set of options instructing Rspack on how and where it should output your bundles, assets, and anything else you bundle or load with Rspack.

• Type: Object

output.assetModuleFilename#

• Type: string | ((pathData: PathData, assetInfo?: JsAssetInfo) => string)
• Default: '[hash][ext][query]'

The same as output.filename but for Asset Modules.

[name], [file], [query], [fragment], [base], and [path] are set to an empty string for the assets built from data URI replacements.

The name of the file to be output by the Asset module. This value can be overridden by Rule.generator.filename.

output.asyncChunks#

• Type: boolean
• Default: true

Create async chunks that are loaded on demand.

output.charset#

• Type: boolean
• Default: true

Add charset="utf-8" to the HTML <script> tag.

output.chunkFilename#

• Type: string = '[id].js' | (pathData: PathData, assetInfo?: JsAssetInfo) => string
• Default: Determined by output.filename when it is not a function, otherwise '[id].js'.

This option determines the name of non-initial chunk files. See output.filename option for details on the possible values.

Note that these filenames need to be generated at runtime to send the requests for chunks. Because of this, placeholders like [name] and [chunkhash] need to add a mapping from chunk id to placeholder value to the output bundle with the Rspack runtime. This increases the size and may invalidate the bundle when placeholder value for any chunk changes.

By default [id].js is used or a value inferred from output.filename([name] is replaced with [id] or [id]. is prepended).

module.exports = {
  //...
  output: {
    //...
    chunkFilename: '[id].js',
  },
};

Usage as a function:

module.exports = {
  //...
  output: {
    chunkFilename: pathData => {
      return pathData.chunk.name === 'main' ? '[name].js' : '[name]/[name].js';
    },
  },
};

output.chunkFormat#

• Type: false | 'array-push' | 'commonjs' | 'module' | string
• Default: Determined by target and output.module

The format of chunks (formats included by default are 'array-push' (web/webworker), 'commonjs' (node.js), 'module' (ESM), but others might be added by plugins).

module.exports = {
  output: {
    chunkFormat: 'commonjs',
  },
};

output.chunkLoadTimeout#

• Type: number
• Default: 120000

The Number of milliseconds before chunk request timed out.

module.exports = {
  //...
  output: {
    //...
    chunkLoadTimeout: 30000, // 30 seconds before chunk request timed out.
  },
};

output.chunkLoadingGlobal#

• Type: string
• Default: Determined by output.uniqueName

The global variable is used by Rspack for loading chunks.

module.exports = {
  output: {
    chunkLoadingGlobal: 'myCustomFunc',
  },
};

output.chunkLoading#

• Type: false | 'jsonp' | 'import-scripts' | 'require' | 'async-node' | 'import'

The method to load chunks (methods included by default are 'jsonp' (web), 'import' (ESM), 'importScripts' (webworker), 'require' (sync node.js), 'async-node' (async node.js), but others might be added by plugins). The default value will be determined based on the configuration of target and chunkFormat.

module.exports = {
  output: {
    chunkLoading: 'async-node',
  },
};

output.clean#

• Type: boolean
• Default: false

Before generating the products, delete all files in the output directory.

module.exports = {
  //...
  output: {
    clean: true, // Clean the output directory before emit.
  },
};

output.crossOriginLoading#

• Type: false | 'anonymous' | 'use-credentials'
• Default: false

The crossOriginLoading config allows you to set the crossorigin attribute for dynamically loaded chunks.

If target is 'web', Rspack will dynamically create <script> and <link> tags to load asynchronous JavaScript and CSS resources. Rspack will add the crossorigin attribute to the <script> and <link> tags if the URLs of these resources are on other domains and crossOriginLoading is not false.

Optional values

crossOriginLoading has the following optional values:

• false: Do not set the crossorigin attribute.
• 'anonymous': Set crossorigin to 'anonymous' to enable cross-origin without user credentials.
• 'use-credentials': Set crossorigin to 'use-credentials' enable cross-origin with user credentials.

Example

For example, set output.publicPath to https://example.com/ and output.crossOriginLoading to 'anonymous':

const path = require('path');

module.exports = {
  output: {
    publicPath: 'https://example.com/',
    crossOriginLoading: 'anonymous',
  },
};

When Rspack dynamically loads JavaScript resources, it will generate the following HTML:

<script src="https://example.com/foo.js" crossorigin="anonymous"></script>

output.cssChunkFilename#

• Type: string | (pathData: PathData, assetInfo?: JsAssetInfo) => string
• Default: Determined by output.chunkFilename when it is not a function, otherwise '[id].css'.

This option determines the name of non-initial CSS output files on disk. See output.filename option for details on the possible values.

You must not specify an absolute path here. However, feel free to include folders separated by '/'. This specified path combines with the output.path value to pinpoint the location on the disk.

output.cssFilename#

• Type: string | (pathData: PathData, assetInfo?: JsAssetInfo) => string
• Default: Determined by output.filename

This option determines the name of CSS output files on disk. See output.filename option for details on the possible values.

You must not specify an absolute path here. However, feel free to include folders separated by '/'. This specified path combines with the output.path value to pinpoint the location on the disk.

output.devtoolFallbackModuleFilenameTemplate#

• Type: string | function (info)
• Default: undefined

A fallback is used when the template string or function above yields duplicates.

See output.devtoolModuleFilenameTemplate.

output.devtoolModuleFilenameTemplate#

• Type: string = 'webpack://[namespace]/[resource-path]?[loaders]' | function (info) => string
• Default: undefined

This option is only used when devtool uses an option that requires module names.

Customize the names used in each source map's sources array. This can be done by passing a template string or function. For example, when using devtool: 'eval'.

module.exports = {
  //...
  output: {
    devtoolModuleFilenameTemplate:
      'webpack://[namespace]/[resource-path]?[loaders]',
  },
};

The following substitutions are available in template strings

When using a function, the same options are available camel-cased via the info parameter:

module.exports = {
  //...
  output: {
    devtoolModuleFilenameTemplate: info => {
      return `webpack:///${info.resourcePath}?${info.loaders}`;
    },
  },
};

If multiple modules would result in the same name, output.devtoolFallbackModuleFilenameTemplate is used instead for these modules.

output.devtoolNamespace#

• Type: string
• Default: undefined

This option determines the module's namespace used with the output.devtoolModuleFilenameTemplate. When not specified, it will default to the value of: output.uniqueName. It's used to prevent source file path collisions in sourcemaps when loading multiple libraries built with Rspack.

For example, if you have 2 libraries, with namespaces library1 and library2, which both have a file ./src/index.js (with potentially different contents), they will expose these files as webpack://library1/./src/index.js and webpack://library2/./src/index.js.

output.enabledChunkLoadingTypes#

• Type: ('jsonp' | 'import-scripts' | 'require' | 'async-node' | string)[]
• Default: Determined by output.chunkLoading, output.workerChunkLoading and Entry's chunkLoading config.

List of chunk loading types enabled for use by entry points. Will be automatically filled by Rspack. Only needed when using a function as entry option and returning chunkLoading option from there.

module.exports = {
  //...
  output: {
    enabledChunkLoadingTypes: ['jsonp', 'require'],
  },
};

output.enabledLibraryTypes#

• Type: string[]
• Default: Determined by output.library and Entry

List of library types enabled for use by entry points.

module.exports = {
  //...
  output: {
    enabledLibraryTypes: ['module'],
  },
};

output.enabledWasmLoadingTypes#

• Type: ('fetch-streaming' | 'fetch' | 'async-node' | string | false)[]
• Default: Determined by output.wasmLoading and output.workerWasmLoading

List of wasm loading types enabled for use by entry points.

module.exports = {
  //...
  output: {
    enabledWasmLoadingTypes: ['fetch'],
  },
};

output.environment#

Tell Rspack what kind of ES-features may be used in the generated runtime-code.

module.exports = {
  output: {
    environment: {
      // The environment supports arrow functions ('() => { ... }').
      arrowFunction: true,
      // The environment supports async function and await ('async function () { await ... }').
      asyncFunction: true,
      // The environment supports BigInt as literal (123n).
      bigIntLiteral: false,
      // The environment supports const and let for variable declarations.
      const: true,
      // The environment supports destructuring ('{ a, b } = obj').
      destructuring: true,
      // The environment supports an async import() function to import EcmaScript modules.
      dynamicImport: false,
      // The environment supports an async import() when creating a worker, only for web targets at the moment.
      dynamicImportInWorker: false,
      // The environment supports 'for of' iteration ('for (const x of array) { ... }').
      forOf: true,
      // The environment supports 'globalThis'.
      globalThis: true,
      // The environment supports ECMAScript Module syntax to import ECMAScript modules (import ... from '...').
      module: false,
      // Determines if the node: prefix is generated for core module imports in environments that support it.
      // This is only applicable to Webpack runtime code.
      nodePrefixForCoreModules: false,
      // The environment supports optional chaining ('obj?.a' or 'obj?.()').
      optionalChaining: true,
      // The environment supports template literals.
      templateLiteral: true,
    },
  },
};

output.filename#

• Type: string | (pathData: PathData, assetInfo?: JsAssetInfo) => string
• Default: When [output.module](#outputmodule) is true, it is '[name].mjs', otherwise it is '[name].js'.

This option determines the name of each output bundle. The bundle is written to the directory specified by the output.path option.

For a single entry point, this can be a static name.

module.exports = {
  output: {
    filename: 'bundle.js',
  },
};

However, when creating multiple bundles via more than one entry point, code splitting, or various plugins, you should use one of the following substitutions to give each bundle a unique name...

Use Entry name:

module.exports = {
  //...
  output: {
    filename: '[name].bundle.js',
  },
};

Using internal chunk id:

module.exports = {
  //...
  output: {
    filename: '[id].bundle.js',
  },
};

Using hashes generated from the generated content:

module.exports = {
  //...
  output: {
    filename: '[contenthash].bundle.js',
  },
};

Combining multiple substitutions:

module.exports = {
  //...
  output: {
    filename: '[name].[contenthash].bundle.js',
  },
};

Using the function to return the filename:

module.exports = {
  //...
  output: {
    filename: pathData => {
      return pathData.chunk.name === 'main' ? '[name].js' : '[name]/[name].js';
    },
  },
};

Note this option is called filename but you are still allowed to use something like 'js/[name]/bundle.js' to create a folder structure.

Note this option does not affect output files for on-demand-loaded chunks. It only affects output files that are initially loaded. For on-demand-loaded chunk files, the output.chunkFilename option is used. Files created by loaders also aren't affected. In this case, you would have to try the specific loader's available options.

Template String#

The template string below can be used to replace the corresponding file name. Different contexts correspond to different replaceable content, e.g. output.assetModuleFilename supports the use of File Context and Module Context.

Compilation Context#

Content that can be replaced at the compilation level.

Chunk Context#

Content that can be replaced at the chunk level.

Module Context#

Content that can be replaced at the module level.

File Context#

Content that can be replaced at the file level.

Substitutions available on URL-level:

The length of hashes ([hash], [contenthash] or [chunkhash]) can be specified using [hash:16] (defaults to 20). Alternatively, specify output.hashDigestLength to configure the length globally.

It is possible to filter out placeholder replacement when you want to use one of the placeholders in the actual file name. For example, to output a file [name].js, you have to escape the [name] placeholder by adding backslashes between the brackets. So that [\name\] generates [name] instead of getting replaced with the name of the asset.

Example: [\id\] generates [id] instead of getting replaced with the id.

If using a function for this option, the function will be passed an object containing data for the substitutions in the table above. Substitutions will be applied to the returned string too. The passed object will have this type: (properties available depending on context)

type PathData = {
  hash: string;
  hashWithLength: (number) => string;
  chunk: Chunk | ChunkPathData;
  module: Module | ModulePathData;
  contentHashType: string;
  contentHash: string;
  contentHashWithLength: (number) => string;
  filename: string;
  url: string;
  runtime: string | SortableSet<string>;
  chunkGraph: ChunkGraph;
};
type ChunkPathData = {
  id: string | number;
  name: string;
  hash: string;
  hashWithLength: (number) => string;
  contentHash: Record<string, string>;
  contentHashWithLength: Record<string, (number) => string>;
};
type ModulePathData = {
  id: string | number;
  hash: string;
  hashWithLength: (number) => string;
};

output.globalObject#

• Type: string
• Default: 'self'

When targeting a library, especially when library.type is 'umd', this option indicates what global object will be used to mount the library. To make UMD build available on both browsers and Node.js, set output.globalObject option to 'this'. Defaults to self for Web-like targets.

The return value of your entry point will be assigned to the global object using the value of output.library.name. Depending on the value of the type option, the global object could change respectively, e.g., self, global, or globalThis.

For example:

module.exports = {
  // ...
  output: {
    library: 'myLib',
    libraryTarget: 'umd',
    filename: 'myLib.js',
    globalObject: 'this',
  },
};

output.hashDigest#

• Type: string
• Default: 'hex'

The encoding to use when generating the hash. Using 'base64' for filenames might be problematic since it has the character / in its alphabet. Likewise 'latin1' could contain any character.

output.hashDigestLength#

• Type: number
• Default: 20

The prefix length of the hash digest to use.

output.hashFunction#

• Type: 'md4' | 'xxhash64'
• Default: 'md4'

The hashing algorithm to use.

module.exports = {
  //...
  output: {
    hashFunction: 'xxhash64',
  },
};

output.hashSalt#

• Type: string
• Default: undefined

An optional salt to update the hash.

output.hotUpdateChunkFilename#

• Type: string
• Default: "[id].[fullhash].hot-update.js"

Customize the filenames of hot update chunks. See output.filename option for details on the possible values.

The only placeholders allowed here are [id] and [fullhash], the default being:

module.exports = {
  //...
  output: {
    hotUpdateChunkFilename: '[id].[fullhash].hot-update.js',
  },
};

output.hotUpdateGlobal#

• Type: string
• Default: "webpackHotUpdate" + output.uniqueName

Only used when target is set to 'web', which uses JSONP for loading hot updates.

A JSONP function is used to asynchronously load hot-update chunks.

For details see output.chunkLoadingGlobal.

output.hotUpdateMainFilename#

• Type: string
• Default: "[runtime].[fullhash].hot-update.json"

Customize the main hot update filename. [fullhash] and [runtime] are available as placeholder.

output.iife#

• Type: boolean
• Default: true

Tells Rspack to add IIFE wrapper around emitted code.

module.exports = {
  //...
  output: {
    iife: true,
  },
};

output.importFunctionName#

• Type: string
• Default: 'import'

The name of the native import() function. Can be used for polyfilling, e.g. with dynamic-import-polyfill.

module.exports = {
  //...
  output: {
    importFunctionName: '__import__',
  },
};

output.library#

Output a library exposing the exports of your entry point.

• Type: string | string[] | object

Let's take a look at an example.

module.exports = {
  // …
  entry: './src/index.js',
  output: {
    library: 'MyLibrary',
  },
};

Say you have exported a function in your src/index.js entry:

export function hello(name) {
  console.log(`hello ${name}`);
}

Now the variable MyLibrary will be bound with the exports of your entry file, and here's how to consume the Rspack bundled library:

<script src="https://example.org/path/to/my-library.js"></script>
<script>
  MyLibrary.hello('rspack');
</script>

In the above example, we're passing a single entry file to entry, however, Rspack can accept many kinds of entry point, e.g., an array, or an object.

1. If you provide an array as the entry point, only the last one in the array will be exposed.

   module.exports = {
     // …
     entry: ['./src/a.js', './src/b.js'], // 只有在 b.js 中导出的内容才会被暴露
     output: {
       library: 'MyLibrary',
     },
   };

2. If an object is provided as the entry point, all entries can be exposed using the array syntax of library:

   module.exports = {
     // …
     entry: {
       a: './src/a.js',
       b: './src/b.js',
     },
     output: {
       filename: '[name].js',
       library: ['MyLibrary', '[name]'], // name is a placeholder here
     },
   };

   Assuming that both a.js and b.js export a function hello, here's how to consume the libraries:

   <script src="https://example.org/path/to/a.js"></script>
   <script src="https://example.org/path/to/b.js"></script>
   <script>
     MyLibrary.a.hello('rspack');
     MyLibrary.b.hello('rspack');
   </script>

output.library.amdContainer#

• Type: string

Use a container(defined in global space) for calling define/require functions in an AMD module.

module.exports = {
  // …
  output: {
    library: {
      amdContainer: 'window["clientContainer"]',
      type: 'amd', // or 'amd-require'
    },
  },
};

Which will result in the following bundle:

window['clientContainer'].define(/*define args*/); // or 'amd-require' window['clientContainer'].require(/*require args*/);

output.library.name#

Specify a name for the library.

• Type: string | string[] | {amd?: string, commonjs?: string, root?: string | string[]}

module.exports = {
  // …
  output: {
    library: {
      name: 'MyLibrary',
    },
  },
};

output.library.type#

Configure how the library will be exposed.

• Type: string

  Types included by default are 'var', 'module', 'system', 'assign', 'assign-properties', 'this', 'window', 'self', 'global', 'commonjs', 'commonjs2', 'commonjs-module', 'commonjs-static', 'amd', 'amd-require', 'umd', 'umd2', but others might be added by plugins.

For the following examples, we'll use _entry_return_ to indicate the values returned by the entry point.

Expose a Variable#

These options assign the return value of the entry point (e.g. whatever the entry point exported) to the name provided by output.library.name at whatever scope the bundle was included at.

type: 'var'#

module.exports = {
  // …
  output: {
    library: {
      name: 'MyLibrary',
      type: 'var',
    },
  },
};

When your library is loaded, the return value of your entry point will be assigned to a variable:

var MyLibrary = _entry_return_;

// In a separate script with `MyLibrary` loaded…
MyLibrary.doSomething();

type: 'assign'#

module.exports = {
  // …
  output: {
    library: {
      name: 'MyLibrary',
      type: 'assign',
    },
  },
};

This will generate an implied global which has the potential to reassign an existing value (use with caution):

MyLibrary = _entry_return_;

Be aware that if MyLibrary isn't defined earlier your library will be set in global scope.

type: 'assign-properties'#

module.exports = {
  // …
  output: {
    library: {
      name: 'MyLibrary',
      type: 'assign-properties',
    },
  },
};

Similar to type: 'assign' but a safer option as it will reuse MyLibrary if it already exists:

// only create MyLibrary if it doesn't exist
MyLibrary = typeof MyLibrary === 'undefined' ? {} : MyLibrary;
// then copy the return value to MyLibrary
// similarly to what Object.assign does

// for instance, you export a `hello` function in your entry as follow
export function hello(name) {
  console.log(`Hello ${name}`);
}

// In another script with MyLibrary loaded
// you can run `hello` function like so
MyLibrary.hello('World');

Expose Via Object Assignment#

These options assign the return value of the entry point (e.g. whatever the entry point exported) to a specific object under the name defined by output.library.name.

type: 'this'#

module.exports = {
  // …
  output: {
    library: {
      name: 'MyLibrary',
      type: 'this',
    },
  },
};

The return value of your entry point will be assigned to this under the property named by output.library.name. The meaning of this is up to you:

this['MyLibrary'] = _entry_return_;

// In a separate script
this.MyLibrary.doSomething();
MyLibrary.doSomething(); // if `this` is window

type: 'window'#

module.exports = {
  // …
  output: {
    library: {
      name: 'MyLibrary',
      type: 'window',
    },
  },
};

The return value of your entry point will be assigned to the window object using the output.library.name value.

window['MyLibrary'] = _entry_return_;

window.MyLibrary.doSomething();

type: 'global'#

module.exports = {
  // …
  output: {
    library: {
      name: 'MyLibrary',
      type: 'global',
    },
  },
};

The return value of your entry point will be assigned to the global object using the output.library.name value. Depending on the target value, the global object could change respectively, e.g., self, global or globalThis.

global['MyLibrary'] = _entry_return_;

global.MyLibrary.doSomething();

type: 'commonjs'#

module.exports = {
  // …
  output: {
    library: {
      name: 'MyLibrary',
      type: 'commonjs',
    },
  },
};

The return value of your entry point will be assigned to the exports object using the output.library.name value. As the name implies, this is used in CommonJS environments.

exports['MyLibrary'] = _entry_return_;

require('MyLibrary').doSomething();

Module Definition Systems#

These options will result in a bundle that comes with a complete header to ensure compatibility with various module systems. The output.library.name option will take on a different meaning under the following output.library.type options.

type: 'module'#

module.exports = {
  // …
  experiments: {
    outputModule: true,
  },
  output: {
    library: {
      // do not specify a `name` here
      type: 'module',
    },
  },
};

Output ES Module.

However this feature is still experimental and not fully supported yet, so make sure to enable experiments.outputModule beforehand. In addition, you can track the development progress in this thread.

type: 'commonjs2'#

module.exports = {
  // …
  output: {
    library: {
      // note there's no `name` here
      type: 'commonjs2',
    },
  },
};

The return value of your entry point will be assigned to the module.exports. As the name implies, this is used in Node.js (CommonJS) environments:

module.exports = _entry_return_;

require('MyLibrary').doSomething();

If we specify output.library.name with type: commmonjs2, the return value of your entry point will be assigned to the module.exports.[output.library.name].

type: 'commonjs-static'#

module.exports = {
  // …
  output: {
    library: {
      // note there's no `name` here
      type: 'commonjs-static',
    },
  },
};

Individual exports will be set as properties on module.exports. The "static" in the name refers to the output being statically analysable, and thus named exports are importable into ESM via Node.js:

Input:

export function doSomething() {}

Output:

function doSomething() {}

// …

exports.doSomething = __webpack_exports__.doSomething;

Consumption (CommonJS):

const { doSomething } = require('./output.cjs'); // doSomething => [Function: doSomething]

Consumption (ESM):

import { doSomething } from './output.cjs'; // doSomething => [Function: doSomething]

type: 'amd'#

This will expose your library as an AMD module.

AMD modules require that the entry chunk (e.g. the first script loaded by the <script> tag) be defined with specific properties, such as to define and require which is typically provided by RequireJS or any compatible loaders (such as almond). Otherwise, loading the resulting AMD bundle directly will result in an error like define is not defined.

With the following configuration:

module.exports = {
  //...
  output: {
    library: {
      name: 'MyLibrary',
      type: 'amd',
    },
  },
};

The generated output will be defined with the name "MyLibrary", i.e.:

define('MyLibrary', [], function () {
  return _entry_return_;
});

The bundle can be included as part of a script tag, and the bundle can be invoked like so:

require(['MyLibrary'], function (MyLibrary) {
  // Do something with the library...
});

If output.library.name is undefined, the following is generated instead.

define(function () {
  return _entry_return_;
});

This bundle will not work as expected, or not work at all (in the case of the almond loader) if loaded directly with a <script> tag. It will only work through a RequireJS compatible asynchronous module loader through the actual path to that file, so in this case, the output.path and output.filename may become important for this particular setup if these are exposed directly on the server.

type: 'amd-require'#

module.exports = {
  //...
  output: {
    library: {
      name: 'MyLibrary',
      type: 'amd-require',
    },
  },
};

This packages your output with an immediately executed AMD require(dependencies, factory) wrapper.

The 'amd-require' type allows for the use of AMD dependencies without needing a separate later invocation. As with the 'amd' type, this depends on the appropriate require function being available in the environment in which the Rspack output is loaded.

With this type, the library name can't be used.

type: 'umd'#

This exposes your library under all the module definitions, allowing it to work with CommonJS, AMD, and as global variable. Take a look at the UMD Repository to learn more.

In this case, you need the library.name property to name your module:

module.exports = {
  //...
  output: {
    library: {
      name: 'MyLibrary',
      type: 'umd',
    },
  },
};

And finally the output is:

(function webpackUniversalModuleDefinition(root, factory) {
  if (typeof exports === 'object' && typeof module === 'object')
    module.exports = factory();
  else if (typeof define === 'function' && define.amd) define([], factory);
  else if (typeof exports === 'object') exports['MyLibrary'] = factory();
  else root['MyLibrary'] = factory();
})(global, function () {
  return _entry_return_;
});

Note that omitting library.name will result in the assignment of all properties returned by the entry point be assigned directly to the root object, as documented under the object assignment section. Example:

module.exports = {
  //...
  output: {
    libraryTarget: 'umd',
  },
};

The output will be:

(function webpackUniversalModuleDefinition(root, factory) {
  if (typeof exports === 'object' && typeof module === 'object')
    module.exports = factory();
  else if (typeof define === 'function' && define.amd) define([], factory);
  else {
    var a = factory();
    for (var i in a) (typeof exports === 'object' ? exports : root)[i] = a[i];
  }
})(global, function () {
  return _entry_return_;
});

You may specify an object for library.name for differing names per targets:

module.exports = {
  //...
  output: {
    library: {
      name: {
        root: 'MyLibrary',
        amd: 'my-library',
        commonjs: 'my-common-library',
      },
      type: 'umd',
    },
  },
};

type: 'system'#

This will expose your library as a System.register module.

System modules require that a global variable System is present in the browser when the Rspack bundle is executed. Compiling to System.register format allows you to System.import('/bundle.js') without additional configuration and has your Rspack bundle loaded into the System module registry.

module.exports = {
  //...
  output: {
    library: {
      type: 'system',
    },
  },
};

Output:

System.register([], function (__WEBPACK_DYNAMIC_EXPORT__, __system_context__) {
  return {
    execute: function () {
      // ...
    },
  };
});

By adding output.library.name to configuration in addition to having output.library.type set to system, the output bundle will have the library name as an argument to System.register:

System.register(
  'MyLibrary',
  [],
  function (__WEBPACK_DYNAMIC_EXPORT__, __system_context__) {
    return {
      execute: function () {
        // ...
      },
    };
  },
);

Other Types#

type: 'jsonp'

module.exports = {
  // …
  output: {
    library: {
      name: 'MyLibrary',
      type: 'jsonp',
    },
  },
};

This will wrap the return value of your entry point into a jsonp wrapper.

MyLibrary(_entry_return_);

The dependencies for your library will be defined by the externals config.

output.library.export#

Specify which export should be exposed as a library.

• Type: string | string[]
• Default: undefined

It is undefined by default, which will export the whole (namespace) object. The examples below demonstrate the effect of this configuration when using output.library.type: 'var'.

module.exports = {
  output: {
    library: {
      name: 'MyLibrary',
      type: 'var',
      export: 'default',
    },
  },
};

The default export of your entry point will be assigned to the library name:

// If your library has a default export
var MyLibrary = _entry_return_.default;

You can pass an array to output.library.export as well, it will be interpreted as a path to a module to be assigned to the library name:

module.exports = {
  output: {
    library: {
      name: 'MyLibrary',
      type: 'var',
      export: ['default', 'subModule'],
    },
  },
};

And here's the library code:

var MyLibrary = _entry_return_.default.subModule;

output.library.auxiliaryComment#

Add a comment in the UMD wrapper.

• Type: string | { amd?: string, commonjs?: string, commonjs2?: string, root?: string }
• Default: undefined

To insert the same comment for each umd type, set auxiliaryComment to a string:

module.exports = {
  // …
  mode: 'development',
  output: {
    library: {
      name: 'MyLibrary',
      type: 'umd',
      auxiliaryComment: 'Test Comment',
    },
  },
};

which will yield the following:

(function webpackUniversalModuleDefinition(root, factory) {
  //Test Comment
  if (typeof exports === 'object' && typeof module === 'object')
    module.exports = factory();
  //Test Comment
  else if (typeof define === 'function' && define.amd) define([], factory);
  //Test Comment
  else if (typeof exports === 'object') exports['MyLibrary'] = factory();
  //Test Comment
  else root['MyLibrary'] = factory();
})(self, function () {
  return _entry_return_;
});

For fine-grained control, pass an object:

module.exports = {
  // …
  mode: 'development',
  output: {
    library: {
      name: 'MyLibrary',
      type: 'umd',
      auxiliaryComment: {
        root: 'Root Comment',
        commonjs: 'CommonJS Comment',
        commonjs2: 'CommonJS2 Comment',
        amd: 'AMD Comment',
      },
    },
  },
};

output.library.umdNamedDefine#

• Type: boolean
• Default: undefined

When using output.library.type: "umd", setting output.library.umdNamedDefine to true will name the AMD module of the UMD build. Otherwise, an anonymous define is used.

module.exports = {
  //...
  output: {
    library: {
      name: 'MyLibrary',
      type: 'umd',
      umdNamedDefine: true,
    },
  },
};

The AMD module will be:

define('MyLibrary', [], factory);

output.module#

• Type: boolean
• Default: false

Output JavaScript files as module type. Disabled by default as it's an experimental feature. To use it, you must set experiments.outputModule to true.

When enabled, Rspack will set output.iife to false, output.scriptType to 'module' and terserOptions.module to true internally.

If you're using Rspack to compile a library to be consumed by others, make sure to set output.libraryTarget to 'module' when output.module is true.

module.exports = {
  //...
  experiments: {
    outputModule: true,
  },
  output: {
    module: true,
  },
};

output.path#

• Type: string
• Default: path.resolve(process.cwd(), 'dist')

The output directory as an absolute path.

const path = require('path');

module.exports = {
  output: {
    path: path.resolve(__dirname, 'dist/assets'),
  },
};

Note that [fullhash] in this parameter will be replaced with a hash of the compilation.

output.pathinfo#

• Type: boolean | 'verbose'
• Default: true

Tells Rspack to include comments in bundles with information about the contained modules. This option defaults to true in development and false in production mode respectively. 'verbose' shows more information like exports, runtime requirements and bailouts.

module.exports = {
  //...
  output: {
    pathinfo: true,
  },
};

output.publicPath#

• Type: 'auto' | string | ((pathData: PathData, assetInfo?: JsAssetInfo) => string)
• Default: 'auto' when targets is 'web' or 'webworker'. undefined otherwise

This option determines the URL prefix of the referenced resource, such as: image, file, etc.

For example, given a configuration file.

module.exports = {
  output: {
    publicPath: '/assets/',
    chunkFilename: '[id].chunk.js',
    assetModuleFilename: '[name][ext]',
  },
};

For a non-initial chunk file, its request URL looks like this: /assets/1.chunk.js.

For a reference to an image, the request URL looks like this: /assets/logo.png.

Also, it is useful when you deploy the product using a CDN

module.exports = {
  output: {
    publicPath: 'https://cdn.example.com/assets/',
    assetModuleFilename: '[name][ext]',
  },
};

For all asset resources, their request URLs look like this: https://cdn.example.com/assets/logo.png.

Dynamically set publicPath

You can set publicPath dynamically using __webpack_public_path__ in the runtime code, and the __webpack_public_path__ will override the publicPath in the Rspack config, but it will only take effect for dynamically loaded resources.

First create a publicPath.js:

__webpack_public_path__ = 'https://cdn.example.com/assets/';

Then import it into the first line of the entry file:

import './publicPath.js';
import './others.js';

output.scriptType#

• Type: 'module' | 'text/javascript' | boolean
• Default: false

This option allows loading asynchronous chunks with a custom script type, such as <script type="module" ...>.

module.exports = {
  //...
  output: {
    scriptType: 'module',
  },
};

output.sourceMapFilename#

• Type: string
• Default: '[file].map[query]'

Configure how source maps are named. Only takes effect when devtool is set to 'source-map', which writes an output file.

The [name], [id], [fullhash] and [chunkhash] substitutions from output.filename can be used. In addition to those, you can use substitutions listed under Filename-level in Template strings.

output.strictModuleErrorHandling#

• Type: boolean
• Default: false

Handle error in module loading as per EcmaScript Modules spec at a performance cost.

module.exports = {
  //...
  output: {
    strictModuleErrorHandling: true,
  },
};

output.trustedTypes#

• Type: true | string | object
• Default: undefined

Controls Trusted Types compatibility. When enabled, Rspack will detect Trusted Types support and, if they are supported, use Trusted Types policies to create script URLs it loads dynamically. Use when the application runs under a require-trusted-types-for Content Security Policy directive.

It is disabled by default (no compatibility, script URLs are strings).

• When set to true, Rspack will use output.uniqueName as the Trusted Types policy name.
• When set to a non-empty string, its value will be used as a policy name.
• When set to an object, the policy name is taken from the object's policyName property.

module.exports = {
  //...
  output: {
    trustedTypes: {
      policyName: 'my-application#webpack',
    },
  },
};

output.uniqueName#

• Type: string
• Default: It defaults to output.library name or the package name from package.json in the context, if both aren't found, it is set to an ''.

A unique name of the Rspack build to avoid multiple Rspack runtimes to conflict when using globals.

output.uniqueName will be used to generate unique globals for:

• output.chunkLoadingGlobal

module.exports = {
  output: {
    uniqueName: 'my-package-xyz',
  },
};

output.wasmLoading#

• Type: false | 'fetch', 'async-node'
• Default: 'fetch'

Option to set the method of loading WebAssembly Modules. Methods included by default are 'fetch' (web/webworker), 'async-node' (Node.js), but others might be added by plugins.

The default value can be affected by different target:

• Defaults to 'fetch' if target is set to 'web', 'webworker', 'electron-renderer' or 'node-webkit'.
• Defaults to 'async-node' if target is set to 'node', 'async-node', 'electron-main' or 'electron-preload'.

module.exports = {
  //...
  output: {
    wasmLoading: 'fetch',
  },
};

output.webassemblyModuleFilename#

• Type: string
• Default: '[hash].module.wasm'

Specifies the filename of WebAssembly modules. It should be provided as a relative path within the output.path directory

module.exports = {
  //...
  output: {
    webassemblyModuleFilename: '[id].[hash].wasm',
  },
};

output.workerChunkLoading#

• Type: false | 'jsonp' | 'import-scripts' | 'require' | 'async-node' | 'import'
• Default: false

The new option workerChunkLoading controls the chunk loading of workers.

module.exports = {
  //...
  output: {
    workerChunkLoading: false,
  },
};

output.workerPublicPath#

• Type: string
• Default: ""

Set a public path for Worker, defaults to value of output.publicPath. Only use this option if your worker scripts are located in a different path from your other scripts.

module.exports = {
  //...
  output: {
    workerPublicPath: '/workerPublicPath2/',
  },
};

output.workerWasmLoading#

• Type: false | 'fetch-streaming' | 'fetch' | 'async-node' | string
• Default: false

Option to set the method of loading WebAssembly Modules in workers, defaults to the value of output.wasmLoading.

module.exports = {
  //...
  output: {
    workerWasmLoading: 'fetch',
  },
};
```import { de } from 'date-fns/locale';

output.auxiliaryComment#

output.libraryExport#

output.libraryTarget#