CC 4.0 License

The content of this section is derived from the content of the following links and is subject to the CC BY 4.0 license.

The following contents can be assumed to be the result of modifications and deletions based on the original contents if not specifically stated.

Module Methods

This section covers all methods available in code compiled with Rspack. When using Rspack to bundle your application, you can pick from a variety of module syntax styles including ES6, CommonJS.

While Rspack supports multiple module syntaxes, we recommend following a single syntax for consistency and to avoid odd behaviors/bugs.

Actually Rspack would enforce the recommendation for .mjs files, .cjs files or .js files when their nearest parent package.json file contains a "type" field with a value of either "module" or "commonjs". Please pay attention to these enforcements before you read on:

  • .mjs or .js with "type": "module" in package.json
    • No CommonJS allowed, for example, you can't use require, module.exports or exports
    • File extensions are required when importing, e.g, you should use import './src/App.mjs' instead of import './src/App' (you can disable this enforcement with Rule.resolve.fullySpecified)
  • .cjs or .js with "type": "commonjs" in package.json
    • Neither import nor export is available

Rspack support ES6 module syntax natively, you can use static import, export and import() syntax.


Keep in mind that you will still probably need SWC or Babel for other ES6+ features.


Statically import the exports of another module.

import MyModule from './my-module.js';
import { NamedExport } from './other-module.js';

You can also import Data URI:

import 'data:text/javascript;charset=utf-8;base64,Y29uc29sZS5sb2coJ2lubGluZSAxJyk7';
import {
} from 'data:text/javascript;charset=utf-8;base64,ZXhwb3J0IGNvbnN0IG51bWJlciA9IDQyOwpleHBvcnQgY29uc3QgZm4gPSAoKSA9PiAiSGVsbG8gd29ybGQiOw==';


Export anything as a default or named export.

// Named exports
export var Count = 5;
export function Multiply(a, b) {
  return a * b;

// Default export
export default {
  // Some data...

Dynamic import()

function import(path: string): Promise;

Dynamically load modules. Calls to import() are treated as split points, meaning the requested module and its children are split out into a separate chunk.

if ( {
  import('lodash').then(_ => {
    // Do something with lodash (a.k.a '_')...

This feature relies on Promise internally. If you use import() with older browsers, remember to shim Promise using a polyfill such as es6-promise or promise-polyfill.

Dynamic expressions in import()

It is not possible to use a fully dynamic import statement, such as import(foo). Because foo could potentially be any path to any file in your system or project.

The import() must contain at least some information about where the module is located. Bundling can be limited to a specific directory or set of files so that when you are using a dynamic expression - every module that could potentially be requested on an import() call is included. For example, import(./locale/${language}.json) will cause every .json file in the ./locale directory to be bundled into the new chunk. At run time, when the variable language has been computed, any file like english.json or german.json will be available for consumption.

// imagine we had a method to get language from cookies or other storage
const language = detectVisitorLanguage();
import(`./locale/${language}.json`).then(module => {
  // do something with the translations

Magic Comments

Rspack/Webpack specific

Inline comments to make features work. By adding comments to the import, we can do things such as name our chunk or select different modes. For a full list of these magic comments see the code below followed by an explanation of what these comments do.

// Single target
  /* webpackChunkName: "my-chunk-name" */
  /* webpackMode: "lazy" */
  /* webpackFetchPriority: "high" */

// Multiple possible targets
  /* webpackInclude: /\.json$/ */
  /* webpackExclude: /\.noimport\.json$/ */
  /* webpackChunkName: "my-chunk-name" */
  /* webpackMode: "lazy" */
  /* webpackPrefetch: true */
  /* webpackPreload: true */
  • Type: boolean

Disables dynamic import parsing when set to true.


Note that setting webpackIgnore to true opts out of code splitting.

  • Type: "eager" | "lazy" | "weak" | "lazy-once"

Different modes for resolving dynamic imports can be specified. The following options are supported:

  • 'lazy' (default): Generates a lazy-loadable chunk for each import()ed module.
  • 'lazy-once': Generates a single lazy-loadable chunk that can satisfy all calls to import(). The chunk will be fetched on the first call to import(), and subsequent calls to import() will use the same network response. Note that this only makes sense in the case of a partially dynamic statement, e.g. import("./locales/${language}.json"), where multiple module paths that can potentially be requested.
  • 'eager':Generates no extra chunk. All modules are included in the current chunk and no additional network requests are made. A Promise is still returned but is already resolved. In contrast to a static import, the module isn't executed until the call to import() is made.
  • 'weak':Tries to load the module if the module function has already been loaded in some other way (e.g. another chunk imported it or a script containing the module was loaded). A Promise is still returned, but only successfully resolves if the chunks are already on the client. If the module is not available, the Promise is rejected. A network request will never be performed. This is useful for universal rendering when required chunks are always manually served in initial requests (embedded within the page), but not in cases where app navigation will trigger an import not initially served.
  • Type:
    • number: chunk prefetch priority
    • boolean: false means not to prefetch, true means priority is 0

Tells the browser that the resource is probably needed for some navigation in the future, see Prefetching/Preloading modules for more details.

  • Type:
    • number: chunk preload priority
    • boolean: false means not to preload, true means priority is 0

Tells the browser that the resource might be needed during the current navigation, , see Prefetching/Preloading modules for more details.

  • Type:: string

A name for the new chunk.

  • Type:: "low" | "high" | "auto"

Set fetchPriority for specific dynamic imports. It's also possible to set a global default value for all dynamic imports by using the module.parser.javascript.dynamicImportFetchPriority option.

  • Type:: Regexp

A regular expression that will be matched against during import resolution. Only modules that match will be bundled.

  • Type:: Regexp

A regular expression that will be matched against during import resolution. Any module that matches will not be bundled.


Note that webpackInclude and webpackExclude options do not interfere with the prefix. eg: ./locale.


Rspack is also support CommonJS syntax natively, you can use require and module.exports methods.


Synchronously retrieve the exports from another module.

require(dependency: string);


Synchronously retrieve a module's ID. It is recommended to treat it as an opaque value which can only be used with require.cache[id] or __webpack_require__(id) (best to avoid such usage).

require.resolve(dependency: string);

Module ID's type can be a number or a string depending on the optimization.moduleIds configuration.


Multiple requires of the same module result in only one module execution and only one export. Therefore a cache in the runtime exists. Removing values from this cache causes new module execution and a new export.

var d1 = require('dependency');
require('dependency') === d1;
delete require.cache[require.resolve('dependency')];
require('dependency') !== d1;


Rspack/Webpack specific

require.context is a function specific to webpack that allows you to dynamically require a set of modules.

You can use require.context in your code, and Rspack will parse and reference the matching modules during the build process.


The return value of require.context is the same as import.meta.webpackContext. We recommend using import.meta.webpackContext, which is more powerful.

  • Type:
function requireContext(
   * A directory to search.
  directory: string,
   * Whether subdirectories should be searched.
   * @default true
  includeSubdirs?: boolean,
   * A regular expression to match files.
   * @default /^\.\/.*$/ (any file)
  filter?: RegExp,
   * Module loading mode.
   * @default 'sync'
  mode?: 'sync' | 'eager' | 'weak' | 'lazy' | 'lazy-once',
): Context;
  • Example:
// Create a context, with files from the test directory that
// can be required with a request ending with `.test.js`.
const context = require.context('./test', false, /\.test\.js$/);
// Create a context with all files in the parent folder and
// descending folders ending with `.stories.js`.
const context = require.context('../', true, /\.stories\.js$/);
// If mode is set to 'lazy', the underlying modules will be loaded asynchronously
const context = require.context('./locales', true, /\.json$/, 'lazy');

The arguments passed to require.context() must be literals.

Data URI Module

Rspack supports importing Data URI modules using the import and require syntax.


import DataURI from 'data:text/javascript,export default 42';


require('data:text/javascript,module.exports = 42');

In addition, Base64 encoded requests are also supported:

const {
} = require('data:text/javascript;charset=utf-8;base64,ZXhwb3J0IGNvbnN0IG51bWJlciA9IDQyOwpleHBvcnQgZnVuY3Rpb24gZm4oKSB7CiAgcmV0dXJuICJIZWxsbyB3b3JsZCI7Cn0=');

The Data URI module can be used as a method to implement virtual modules, such as combining with a Loader to dynamically load custom modules at runtime.