> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# output

## output.module [![output.module](https://assets.rspack.rs/rsbuild/rsbuild-logo.svg)output.module](https://rsbuild.rs/config/output/module)
- **Type:** `boolean`
- **Default:** `true`
- **CLI:** `--output.module`

Whether to output JavaScript files in ES module format.

Rstest outputs and executes test code in ES module format by default. If you want to output test code in CommonJS format, you can enable it through the following configuration:

```ts title="rstest.config.ts"
import { defineConfig } from '@rstest/core';

export default defineConfig({
  output: {
    module: false,
  },
});
```

### Commonjs interop

When you output JavaScript files in ES module format (`output.module: true`), Rstest will determine the type of external based on how the dependency is imported:

- Dependencies imported via `import` syntax will be treated as ES module type externals.
- Dependencies imported via `require` syntax will be treated as CommonJS externals.

When you import CommonJS modules using the `import` syntax, Rstest will attempt interop handling, allowing you to import CommonJS module exports normally using `import` syntax. The following code works correctly in Rstest:

```ts title="cjs-module"
Object.defineProperty(exports, '__esModule', { value: true });

const a = require('./a');

exports.a = a.a;

exports.default = () => {
  return `hello ${a.a}`;
};
```

```ts title="test/index.test.ts"
import defaultExport, { a } from 'cjs-module';
```

However, this interop handling does not always work perfectly, depending on the way the CommonJS module exports its content. Currently, Rstest does not support interop CommonJS module default exports as named exports.

```ts
function lodash(_value) {}

lodash.VERSION = VERSION;

module.exports = lodash;
```

```ts
import { VERSION } from 'lodash'; // ❌
```

If you encounter issues during usage, you can specify the external type of a dependency as CommonJS through [specifying external type](#specify-external-type).

```ts title="rstest.config.ts"
import { defineConfig } from '@rstest/core';

export default defineConfig({
  output: {
    externals: {
      lodash: 'commonjs lodash', // externalize lodash as a CommonJS module
    },
  },
});
```

## output.externals [![output.externals](https://assets.rspack.rs/rsbuild/rsbuild-logo.svg)output.externals](https://rsbuild.rs/config/output/externals)
Prevent some `import` dependencies from being packed into bundles in your code, and instead Rstest will `import` them at runtime.

- In the Node.js test environment, Rstest will bundle and transpile the following files by default:
  - Any TypeScript and JSX files in any directory, with file extensions `.ts`, `.tsx`, `.jsx`, `.mts`, `.cts`.
  - JavaScript files outside the `node_modules` directory, with file extensions `.js`, `.mjs`, `.cjs`.
- In the browser-like (jsdom, etc) test environment, all packages are bundled by default.

If you want a dependency to be externalized, you can configure it in `output.externals`.

```ts title="rstest.config.ts"
import { defineConfig } from '@rstest/core';

export default defineConfig({
  output: {
    externals: ['react'],
  },
});
```

If you want all dependencies to be bundled, you can configure it through the following configuration:

```ts title="rstest.config.ts"
import { defineConfig } from '@rstest/core';

export default defineConfig({
  tools: {
    rspack: (config) => {
      config.externals = [];
    },
  },
});
```

### Specify external type

You can use `${externalsType} ${libraryName}` syntax to specify the external type of a dependency.

For example, you can use `commonjs lodash` to specify that `lodash` should be externalized as a CommonJS module:

```ts title="rstest.config.ts"
import { defineConfig } from '@rstest/core';

export default defineConfig({
  output: {
    externals: {
      lodash: 'commonjs lodash',
    },
  },
});
```

You can also specify the default external type for all dependencies through the [`externalsType` configuration option](https://rspack.rs/config/externals#externalstype).

```ts title="rstest.config.ts"
import { defineConfig } from '@rstest/core';

export default defineConfig({
  tools: {
    rspack: {
      externalsType: 'commonjs',
    },
  },
});
```

## output.bundleDependencies


[Added in v0.9.5](https://github.com/web-infra-dev/rstest/releases/tag/v0.9.5)

- **Type:** `boolean | (string | RegExp)[]`
- **Default:** Depends on `testEnvironment`

Controls whether third-party dependencies from `node_modules` are bundled or externalized.

- `true`: Always bundle all third-party dependencies, regardless of test environment.
- `false`: Always externalize third-party dependencies, regardless of test environment.
- `['pkg-name']`: Bundle only the listed packages and externalize the rest.
- `['pkg-name/subpath']`: Bundle a specific package subpath.
- `['pkg-name/*']`: Bundle package requests that match the glob-like pattern.
- `[/^pkg-name\\/subpath/]`: Bundle package requests that match the regular expression.

When this option is unset, Rstest bundles dependencies in browser-like test environments (jsdom, happy-dom, etc.), and externalizes them in the `node` environment.

:::warning
This option only applies to non-browser mode. In [browser mode](/guide/browser-testing.md), all dependencies are always bundled, so `output.bundleDependencies: false` is not supported.
:::

This option provides a simple way to override the default bundling strategy that is tied to `testEnvironment`. For example, if you use `jsdom` but want the same externalization behavior as the `node` environment:

```ts title="rstest.config.ts"
import { defineConfig } from '@rstest/core';

export default defineConfig({
  testEnvironment: 'jsdom',
  output: {
    bundleDependencies: false,
  },
});
```

Or if you want to bundle all dependencies in the `node` environment to benefit from optimizations like [lazy barrel](https://rspack.rs/guide/optimization/lazy-barrel):

```ts title="rstest.config.ts"
import { defineConfig } from '@rstest/core';

export default defineConfig({
  testEnvironment: 'node',
  output: {
    bundleDependencies: true,
  },
});
```

If you only want to bundle a few packages while keeping the rest externalized, pass their package names:

```ts title="rstest.config.ts"
import { defineConfig } from '@rstest/core';

export default defineConfig({
  output: {
    bundleDependencies: ['strip-ansi'],
  },
});
```

You can also target subpaths or patterns:

```ts title="rstest.config.ts"
import { defineConfig } from '@rstest/core';

export default defineConfig({
  output: {
    bundleDependencies: ['strip-ansi/lib/index.js', 'strip-ansi/*'],
  },
});
```

Patterns only affect dependency requests that rstest can still process in the current bundle graph. If a package has already been externalized, its internal dependencies stay external as well. In other words, `bundleDependencies` does not re-bundle transitive dependencies that are reachable only through an externalized parent package.

### Relationship with output.externals

Both options decide whether a dependency is bundled or externalized, but they work at different levels. Think of it as "set the baseline first, then make exceptions":

- **`output.bundleDependencies` sets the overall baseline**: it decides, in one shot, whether all `node_modules` dependencies default to being bundled or externalized.
- **[`output.externals`](#outputexternals) makes per-package exceptions**: on top of that baseline, it targets individual packages, and takes higher priority.

#### Listing a package has the opposite effect

When you only need to adjust a few packages, the two options express opposite intents:

- `bundleDependencies: ['foo']` externalizes every dependency by default and bundles only `foo`.
- `externals: ['foo']` bundles every dependency by default and externalizes only `foo`.

Which one to use depends on the behavior most of your dependencies should keep:

- Most dependencies should stay externalized, and only a few need bundling → list the packages to bundle in `bundleDependencies`.
- Most dependencies should stay bundled, and only a few need externalizing → list the packages to externalize in `output.externals`. This assumes a bundling baseline (a browser-like environment, or `bundleDependencies: true`), since `output.externals` only adds exceptions on top of the current baseline and does not change it.

#### When both are set, `output.externals` wins

`output.externals` is a native Rspack capability and takes effect before Rstest's overall strategy. So you can use `bundleDependencies` to set a broad baseline, then use `externals` to precisely override individual packages:

```ts title="rstest.config.ts"
import { defineConfig } from '@rstest/core';

export default defineConfig({
  output: {
    // Baseline: bundle all third-party dependencies
    bundleDependencies: true,
    // Exception: keep lodash externalized
    externals: ['lodash'],
  },
});
```

## output.cssModules [![output.cssModules](https://assets.rspack.rs/rsbuild/rsbuild-logo.svg)output.cssModules](https://rsbuild.rs/config/output/css-modules)
For custom CSS Modules configuration.

## output.emitAssets [![output.emitAssets](https://assets.rspack.rs/rsbuild/rsbuild-logo.svg)output.emitAssets](https://rsbuild.rs/config/output/emit-assets)

[Added in v0.9.7](https://github.com/web-infra-dev/rstest/releases/tag/v0.9.7)

- **Type:** `boolean`
- **Default:** `true`
- **CLI:** `--output.emitAssets`

Controls whether imported static assets such as images, fonts, audio, and video are emitted as build assets during test builds.

Rstest forwards this option to the underlying Rsbuild pipeline and follows the same behavior as Rsbuild. When `output.emitAssets` is `true`, imported asset modules are emitted into the build output file system. When it is `false`, those asset files are not emitted.

In Rstest, emitted assets are written to disk only when [dev.writeToDisk](/config/build/dev.md#devwritetodisk) is enabled or when you run with DEBUG output enabled. Otherwise, they stay in the temporary in-memory output used by the test build.

This option is mainly useful when you want Rstest to match an existing Rsbuild setup, or when your tests do not need to validate emitted static assets.

If you are already reusing your Rsbuild config through [@rstest/adapter-rsbuild](/integration/rsbuild.md), `output.emitAssets` is inherited automatically.

## output.distPath [![output.distPath](https://assets.rspack.rs/rsbuild/rsbuild-logo.svg)output.distPath](https://rsbuild.rs/config/output/dist-path)

[Added in v0.9.5](https://github.com/web-infra-dev/rstest/releases/tag/v0.9.5)

- **Type:** `string | { root?: string }`
- **Default:** `{ root: 'dist/.rstest-temp' }`

Control the global root directory where Rstest places its temporary build outputs.

By default, Rstest does not write test temporary files to disk. When you enable the [dev.writeToDisk](/config/build/dev.md#devwritetodisk) option or run in DEBUG mode, Rstest will write temporary artifacts to disk, outputting them to the `dist/.rstest-temp` directory. This includes compiled artifacts used by the Node.js test runtime, as well as temporary resources generated in browser mode such as runner files and virtual manifests.

In multi-project runs, Rstest still uses one global output root. It may create subdirectories under that root for different projects, but the base directory itself is shared and does not switch to each project's `root`.

If you want these files to go to another directory, set `output.distPath.root`:

```ts title="rstest.config.ts"
import { defineConfig } from '@rstest/core';

export default defineConfig({
  dev: {
    writeToDisk: true,
  },
  output: {
    distPath: {
      root: 'custom/.rstest-temp',
    },
  },
});
```

After this change, rstest will use `<root>/custom/.rstest-temp` as the temporary output root instead of `<root>/dist/.rstest-temp`.

## output.cleanDistPath [![output.cleanDistPath](https://assets.rspack.rs/rsbuild/rsbuild-logo.svg)output.cleanDistPath](https://rsbuild.rs/config/output/clean-dist-path)
- **CLI:** `--output.cleanDistPath`

Whether to clean up all test temporary files under the output directory before the test starts.

By default, rstest does not write test temporary files to disk, and this configuration item may be required when you debug rstest outputs.