Interface: OutputOptions

Defined in: options/output-options.ts:100

Properties

advancedChunks?

Type: object with the properties below
Optional

Defined in: options/output-options.ts:541

Allows you to do manual chunking. For deeper understanding, please refer to the in-depth documentation.

groups?

Type: AdvancedChunksGroup[]
Optional

Groups to be used for advanced chunking.

includeDependenciesRecursively?

Type: boolean
Optional

By default, each group will also include captured modules' dependencies. This reduces the chance of generating circular chunks.

If you want to disable this behavior, it's recommended to both set

preserveEntrySignatures: false | 'allow-extension'
experimental.strictExecutionOrder: true

to avoid generating invalid chunks.

Default

true

maxModuleSize?

Type: number
Optional

Global fallback of group.maxModuleSize, if it's not specified in the group.

maxSize?

Type: number
Optional

Global fallback of group.maxSize, if it's not specified in the group.

minModuleSize?

Type: number
Optional

Global fallback of group.minModuleSize, if it's not specified in the group.

minShareCount?

Type: number
Optional

Global fallback of group.minShareCount, if it's not specified in the group.

minSize?

Type: number
Optional

Global fallback of group.minSize, if it's not specified in the group.

Example

Basic vendor chunk

export default defineConfig({
  output: {
    advancedChunks: {
      minSize: 20000,
      groups: [
        {
          name: 'vendor',
          test: /node_modules/,
        },
      ],
    },
  },
});

Multiple chunk groups with priorities

export default defineConfig({
  output: {
    advancedChunks: {
      groups: [
        {
          name: 'react-vendor',
          test: /node_modules[\\/]react/,
          priority: 20,
        },
        {
          name: 'ui-vendor',
          test: /node_modules[\\/](antd%7C@mui)/,
          priority: 15,
        },
        {
          name: 'vendor',
          test: /node_modules/,
          priority: 10,
        },
        {
          name: 'common',
          minShareCount: 2,
          minSize: 10000,
          priority: 5,
        },
      ],
    },
  },
});

Size-based splitting

export default defineConfig({
  output: {
    advancedChunks: {
      groups: [
        {
          name: 'large-libs',
          test: /node_modules/,
          minSize: 100000, // 100KB
          maxSize: 250000, // 250KB
          priority: 10,
        },
      ],
    },
  },
});

assetFileNames?

Type: string | (chunkInfo) => string
Optional

Defined in: options/output-options.ts:295

The pattern to use for naming custom emitted assets to include in the build output, or a function that is called per asset to return such a pattern.

Patterns support the following placeholders:

[extname]: The file extension of the asset including a leading dot, e.g. .css.
[ext]: The file extension without a leading dot, e.g. css.
[hash]: A hash based on the content of the asset. You can also set a specific hash length via e.g. [hash:10]. By default, it will create a base-64 hash. If you need a reduced character set, see output.hashCharacters.
[name]: The file name of the asset excluding any extension.

Forward slashes (/) can be used to place files in sub-directories.

Default

'assets/[name]-[hash][extname]'

Type: string | (chunk) => string | Promise<string>
Optional

Defined in: options/output-options.ts:226

A string to prepend to the bundle before renderChunk hook.

See output.intro, output.postBanner as well.

WARNING

When using output.banner with minification enabled, the banner content may be stripped out unless it is formatted as a legal comment. To ensure your banner persists through minification, do either:

Use output.postBanner instead, which are added after minification, or
Use one of these comment formats:
- Comments starting with /*! (e.g., /*! My banner */)
- Comments containing @license (e.g., /* @license My banner */)
- Comments containing @preserve (e.g., /* @preserve My banner */)
- Comments starting with //! (for single-line comments)

The latter way's behavior is controlled by the output.legalComments option, which defaults to 'inline' and preserves these special comment formats.

chunkFileNames?

Type: string | (chunkInfo) => string
Optional

Defined in: options/output-options.ts:325

The pattern to use for naming shared chunks created when code-splitting, or a function that is called per chunk to return such a pattern.

Patterns support the following placeholders:

[format]: The rendering format defined in the output options, e.g. es or cjs.
[hash]: A hash based only on the content of the final generated chunk, including transformations in renderChunk and any referenced file hashes. You can also set a specific hash length via e.g. [hash:10]. By default, it will create a base-64 hash. If you need a reduced character set, see output.hashCharacters.
[name]: The name of the chunk. This can be explicitly set via the output.advancedChunks option or when the chunk is created by a plugin via this.emitFile. Otherwise, it will be derived from the chunk contents.

Forward slashes (/) can be used to place files in sub-directories.

Default

'[name]-[hash].js'

cleanDir?

Type: boolean
Optional

Defined in: options/output-options.ts:649

Clean output directory (output.dir) before emitting output.

Default

false

Examples

Basic usage

export default {
  output: {
    cleanDir: true,
  },
};

Multiple outputs in one config

When multiple outputs share the same directory, only set cleanDir: true for the first output:

export default {
  output: [
    {
      dir: 'dist',
      format: 'es',
      cleanDir: true, // Clean on first output
    },
    {
      dir: 'dist',
      format: 'cjs',
      // cleanDir defaults to false, so files from first output are preserved
    },
  ],
};

Multiple configurations

When multiple configurations share the same directory, only set cleanDir: true for the first configuration:

export default [
  {
    input: 'src/index.js',
    output: {
      dir: 'dist',
      cleanDir: true, // Clean on first configuration
    },
  },
  {
    input: 'src/other.js',
    output: {
      dir: 'dist',
      // cleanDir defaults to false, so files from first config are preserved
    },
  },
];

Different directories in multiple outputs

When multiple outputs use different directories, you can safely use cleanDir: true for each:

export default {
  output: [
    {
      dir: 'dist/es',
      format: 'es',
      cleanDir: true, // Safe - different directory
    },
    {
      dir: 'dist/cjs',
      format: 'cjs',
      cleanDir: true, // Safe - different directory
    },
  ],
};

In-depth

Execution timing

The timing of the directory cleanup is important for plugin compatibility:

The cleanup occurs before the generateBundle hook is called
Files created by plugins during generateBundle or writeBundle hooks are not deleted
This ensures that plugin-generated files are preserved even when cleanDir is enabled

For advanced use cases involving multiple outputs with the same output.dir, consider using a separate cleanup script for more control over the cleanup process.

⚠️ Multiple configurations behavior

When using multiple configurations or outputs, the cleanDir option will be executed separately for each configuration/output following the order they are defined.

The two patterns:

Multiple configurations: export default defineConfig([{ output: { cleanDir: true, ... } }, { output: {...} }])
Multiple outputs in one config: defineConfig({ output: [{ cleanDir: true, ... }, { ... }] })

The problem:

If multiple outputs share the same output.dir and have cleanDir: true, later outputs may clean files generated by earlier outputs. This happens because each output executes its cleanup independently.

Best practice:

To avoid this issue, only set cleanDir: true for the first output, or use different output directories. This ensures that all generated files are preserved.

dir?

Type: string
Optional

Defined in: options/output-options.ts:108

The directory in which all generated chunks are placed.

The output.file option should be used instead if only a single chunk is generated.

Default

'dist'

dynamicImportInCjs?

Type: boolean
Optional

Defined in: options/output-options.ts:472

Whether to keep external dynamic imports as import(...) expressions in CommonJS output.

If set to false, external dynamic imports will be rewritten to use require(...) calls. This may be necessary to support environments that do not support dynamic import() in CommonJS modules like old Node.js versions.

Default

true

entryFileNames?

Type: string | (chunkInfo) => string
Optional

Defined in: options/output-options.ts:310

The pattern to use for chunks created from entry points, or a function that is called per entry chunk to return such a pattern.

Patterns support the following placeholders:

[format]: The rendering format defined in the output options, e.g. es or cjs.
[hash]: A hash based only on the content of the final generated chunk, including transformations in renderChunk and any referenced file hashes. You can also set a specific hash length via e.g. [hash:10]. By default, it will create a base-64 hash. If you need a reduced character set, see output.hashCharacters.
[name]: The file name (without extension) of the entry point, unless the object form of input was used to define a different name.

Forward slashes (/) can be used to place files in sub-directories. This pattern will also be used for every file when setting the output.preserveModules option.

Default

'[name].js'

esModule?

Type: boolean | "if-default-prop"
Optional

Defined in: options/output-options.ts:279

Whether to add a __esModule: true property when generating exports for non-ES formats.

This property signifies that the exported value is the namespace of an ES module and that the default export of this module corresponds to the .default property of the exported object.

true: Always add the property when using named exports mode, which is similar to what other tools do.
"if-default-prop": Only add the property when using named exports mode and there also is a default export. The subtle difference is that if there is no default export, consumers of the CommonJS version of your library will get all named exports as default export instead of an error or undefined.
false: Never add the property even if the default export would become a property .default.

Default

'if-default-prop'

exports?

Type: "auto" | "named" | "default" | "none"
Optional

Defined in: options/output-options.ts:122

Which exports mode to use.

When 'auto' is used, Rolldown will automatically determine the export mode based on the exports of the input modules. If the input modules have a single default export, then 'default' mode is used. If the input modules have named exports, then 'named' mode is used. If there are no exports, then 'none' mode is used.

'default' can only be used when the input modules have a single default export. 'none' can only be used when the input modules have no exports. Otherwise, Rolldown will throw an error.

The difference between 'default' and 'named' affects how other people can consume your bundle. If you use 'default', a CommonJS user could do this, for example:

// your-lib package entry
export default 'Hello world';

// a CommonJS consumer
/* require( "your-lib" ) returns "Hello world" */
const hello = require('your-lib');

With 'named', a user would do this instead:

// your-lib package entry
export const hello = 'Hello world';

// a CommonJS consumer
/* require( "your-lib" ) returns {hello: "Hello world"} */
const hello = require('your-lib').hello;
/* or using destructuring */
const { hello } = require('your-lib');

The wrinkle is that if you use 'named' exports but also have a default export, a user would have to do something like this to use the default export:

// your-lib package entry
export default 'foo';
export const bar = 'bar';

// a CommonJS consumer
/* require( "your-lib" ) returns {default: "foo", bar: "bar"} */
const foo = require('your-lib').default;
const bar = require('your-lib').bar;
/* or using destructuring */
const { default: foo, bar } = require('your-lib');

TIP

There are many tools that are capable of resolving a CommonJS require(...) call with an ES module. If you are generating CommonJS output that is meant to be interchangeable with ESM output for those tools, you should always use 'named' export mode. The reason is that most of those tools will by default return the namespace of an ES module on require where the default export is the .default property.

In other words for those tools, you cannot create a package interface where const lib = require("your-lib") yields the same as import lib from "your-lib". With 'named' export mode however, const {lib} = require("your-lib") will be equivalent to import {lib} from "your-lib".

Default

'auto'

extend?

Type: boolean
Optional

Defined in: options/output-options.ts:267

Whether to extend the global variable defined by the name option in umd or iife formats.

When true, the global variable will be defined as global.name = global.name || {}. When false, the global defined by name will be overwritten like global.name = {}.

Default

false

externalLiveBindings?

Type: boolean
Optional

Defined in: options/output-options.ts:455

Whether to generate code to support live bindings for external imports.

With the default value of true, Rolldown will generate code to support live bindings for external imports.

When set to false, Rolldown will assume that exports from external modules do not change. This will allow Rolldown to generate smaller code. Note that this can cause issues when there are circular dependencies involving an external dependency.

Default

true

Example

// input
export { x } from 'external';

// CJS output with externalLiveBindings: true
var external = require('external');

Object.defineProperty(exports, 'x', {
  enumerable: true,
  get: function () {
    return external.x;
  },
});

// CJS output with externalLiveBindings: false
var external = require('external');

exports.x = external.x;

file?

Type: string
Optional

Defined in: options/output-options.ts:114

The file path for the single generated chunk.

The output.dir option should be used instead if multiple chunks are generated.

Type: string | (chunk) => string | Promise<string>
Optional

Defined in: options/output-options.ts:234

A string to append to the bundle before renderChunk hook.

See output.outro, output.postFooter as well.

WARNING

When using output.footer with minification enabled, the footer content may be stripped out unless it is formatted as a legal comment. To ensure your footer persists through minification, do either:

Use output.postFooter instead, which is added after minification, or
Use one of these comment formats:
- Comments starting with /*! (e.g., /*! My footer */)
- Comments containing @license (e.g., /* @license My footer */)
- Comments containing @preserve (e.g., /* @preserve My footer */)
- Comments starting with //! (for single-line comments)

The latter way's behavior is controlled by the output.legalComments option, which defaults to 'inline' and preserves these special comment formats.

format?

Type: "es" | "cjs" | "esm" | "module" | "commonjs" | "iife" | "umd"
Optional

Defined in: options/output-options.ts:143

Expected format of generated code.

'es', 'esm' and 'module' are the same format, all stand for ES module.
'cjs' and 'commonjs' are the same format, all stand for CommonJS module.
'iife' stands for Immediately Invoked Function Expression.
'umd' stands for Universal Module Definition.

Default

'esm'

generatedCode?

Type: Partial<GeneratedCodeOptions>
Optional

Defined in: options/output-options.ts:443

Which language features Rolldown can safely use in generated code.

This will not transpile any user code but only change the code Rolldown uses in wrappers and helpers.

globals?

Type: Record<string, string> | (name) => string
Optional

Defined in: options/output-options.ts:406

Specifies id: variableName pairs necessary for external imports in umd / iife bundles.

Example

export default defineConfig({
  external: ['jquery'],
  output: {
    format: 'iife',
    name: 'MyBundle',
    globals: {
      jquery: '$',
    }
  }
});

// input
import $ from 'jquery';

// output
var MyBundle = (function ($) {
  // ...
})($);

hashCharacters?

Type: "base64" | "base36" | "hex"
Optional

Defined in: options/output-options.ts:132

Specify the character set that Rolldown is allowed to use in file hashes.

'base64': Uses url-safe base64 characters (0-9, a-z, A-Z, -, _). This will produce the shortest hashes.
'base36': Uses alphanumeric characters (0-9, a-z)
'hex': Uses hexadecimal characters (0-9, a-f)

Default

'base64'

inlineDynamicImports?

Type: boolean
Optional

Defined in: options/output-options.ts:463

Whether to inline dynamic imports instead of creating new chunks to create a single bundle.

This option can be used only when a single input is provided.

Default

false

intro?

Type: string | (chunk) => string | Promise<string>
Optional

Defined in: options/output-options.ts:252

A string to prepend inside any format-specific wrapper.

See output.banner, output.postBanner as well.

keepNames?

Type: boolean
Optional

Defined in: options/output-options.ts:659

Keep name property of functions and classes after bundling.

When enabled, the bundler will preserve the original name property value of functions and classes in the output. This is useful for debugging and some frameworks that rely on it for registration and binding purposes.

Default

false

legalComments?

Type: "none" | "inline"
Optional

Defined in: options/output-options.ts:585

Control comments in the output.

none: no comments
inline: preserve comments that contain @license, @preserve or starts with //! /*!

manualChunks()?

Type: (moduleId, meta) => string | NullValue
Optional

Defined in: options/output-options.ts:518

Allows you to do manual chunking. Provided for Rollup compatibility.

You could use this option for migration purpose. Under the hood,

{
  manualChunks: (moduleId, meta) => {
    if (moduleId.includes('node_modules')) {
      return 'vendor';
    }
    return null;
  }
}

will be transformed to

{
  advancedChunks: {
    groups: [
      {
        name(moduleId) {
          if (moduleId.includes('node_modules')) {
            return 'vendor';
          }
          return null;
        },
      },
    ],
  }
}

Note that unlike Rollup, object form is not supported.

Parameters

moduleId

string

Returns

string | NullValue

Deprecated

Please use output.advancedChunks instead.

WARNING

If manualChunks and advancedChunks are both specified, manualChunks option will be ignored.

minify?

Type: boolean | MinifyOptions | "dce-only"
Optional

Defined in: options/output-options.ts:356

Control code minification.

true: Enable full minification including code compression and dead code elimination
false: Disable minification (default)
'dce-only': Only perform dead code elimination without code compression
MinifyOptions: Fine-grained control over minification settings

Default

false

minifyInternalExports?

Type: boolean
Optional

Defined in: options/output-options.ts:641

Whether to minify internal exports as single letter variables to allow for better minification.

Default

true for format es or if output.minify is true or object, false otherwise

In-depth

For example, if you have the following code:

// main.js
import './lib.js';

// lib.js
import('./dynamic.js');
export const importantValue = 42;

// dynamic.js
import { importantValue } from './lib.js';
console.log(importantValue);

The output with minifyInternalExports: false will be:

// main.js
import('./dynamic-CCJ-yTfk.js');
const importantValue = 42;

export { importantValue };

// dynamic-CCJ-yTfk.js
import { importantValue } from './index.js';

console.log(importantValue);

On the other hand, the output with minifyInternalExports: true will be:

// main.js
import('./dynamic-CCJ-yTfk.js');
const importantValue = 42;

export { importantValue as t };

// dynamic-CCJ-yTfk.js
import { t as importantValue } from './index.js';

console.log(importantValue);

Even though it appears that setting this option to true makes the output larger, it actually makes it smaller if a minifier is used. In this case, export { importantValue as t } can become e.g., export{t as e} or even export{t}, while otherwise it would produce export{ a as importantValue } because a minifier usually will not change export signatures.

name?

Type: string
Optional

Defined in: options/output-options.ts:378

Specifies the global variable name that contains the exports of umd / iife bundles.

Example

export default defineConfig({
  output: {
    format: 'iife',
    name: 'MyBundle',
  }
});

// output
var MyBundle = (function () {
  // ...
})();

Namespaces are supported i.e., your name can contain dots. The resulting bundle will contain the setup necessary for the namespacing.

// output for `name: 'a.b.c'`
this.a = this.a || {};
this.a.b = this.a.b || {};
this.a.b.c = (function () {
  // ...
})();

outro?

Type: string | (chunk) => string | Promise<string>
Optional

Defined in: options/output-options.ts:258

A string to append inside any format-specific wrapper.

See output.footer, output.postFooter as well.

paths?

Type: Record<string, string> | (id) => string
Optional

Defined in: options/output-options.ts:437

Maps external module IDs to paths.

Allows customizing the path used when importing external dependencies. This is particularly useful for loading dependencies from CDNs or custom locations.

Object form: Maps module IDs to their replacement paths
Function form: Takes a module ID and returns its replacement path

Examples

{
  paths: {
    'd3': 'https://cdn.jsdelivr.net/npm/d3@7'
  }
}

{
  paths: (id) => {
    if (id.startsWith('lodash')) {
      return `https://cdn.jsdelivr.net/npm/${id}`
    }
    return id
  }
}

plugins?

Type: RolldownOutputPluginOption
Optional

Defined in: options/output-options.ts:589

The list of plugins to use only for this output.

polyfillRequire?

Type: boolean
Optional

Defined in: options/output-options.ts:597

Whether to add a polyfill for require() function in non-CommonJS formats.

This option is useful when you want to inject your own require implementation.

Default

true

postBanner?

Type: string | (chunk) => string | Promise<string>
Optional

Defined in: options/output-options.ts:240

A string to prepend to the bundle after renderChunk hook and minification.

See output.banner, output.intro as well.

postFooter?

Type: string | (chunk) => string | Promise<string>
Optional

Defined in: options/output-options.ts:246

A string to append to the bundle after renderChunk hook and minification.

See output.footer, output.outro as well.

preserveModules?

Type: boolean
Optional

Defined in: options/output-options.ts:610

Whether to use preserve modules mode.

Instead of creating as few chunks as possible, this mode will create separate chunks for all modules using the original module names as file names. Tree-shaking will still be applied, suppressing files that are not used by the provided entry points or do not have side effects when executed and removing unused exports of files that are not entry points. On the other hand, if plugins emit additional "virtual" files to achieve certain results, those files will be emitted as actual files using a pattern ${output.virtualDirname}/fileName.js.

It is therefore not recommended to blindly use this option to transform an entire file structure to another format if you directly want to import from those files as expected exports may be missing. In that case, you should rather designate all files explicitly as entry points by adding them to the input option object.

Example of designating all files as entry points

You can do so dynamically, e.g., via the tinyglobby package:

import { defineConfig } from 'rolldown';
import { globSync } from 'tinyglobby';
import path from 'node:path';

export default defineConfig({
  input: Object.fromEntries(
    globSync('src/**/*.js').map((file) => [
      // This removes `src/` as well as the file extension from each
      // file, so e.g., src/nested/foo.js becomes nested/foo
      path.relative('src', file.slice(0, file.length - path.extname(file).length)),
      // This expands the relative paths to absolute paths, so e.g.,
      // src/nested/foo becomes /project/src/nested/foo.js
      path.resolve(file),
    ]),
  ),
  output: {
    format: 'es',
    dir: 'dist',
  },
});

Default

false

preserveModulesRoot?

Type: string
Optional

Defined in: options/output-options.ts:622

A directory path to input modules that should be stripped away from output.dir when using preserve modules mode.

This option is particularly useful when the output directory structure may change. This can happen when third-party modules are not marked external, or while developing in a monorepo of multiple packages that rely on one another and are not marked external.

Examples

import { defineConfig } from 'rolldown';

export default defineConfig({
  input: ['src/module.js', `src/another/module.js`],
  output: {
    dir: 'dist',
    preserveModules: true,
    preserveModulesRoot: 'src',
  },
});

This setting ensures that the input modules will be output to the paths dist/module.js and dist/another/module.js.

sanitizeFileName?

Type: boolean | (name) => string
Optional

Defined in: options/output-options.ts:345

Whether to enable chunk name sanitization (removal of non-URL-safe characters like \0, ? and *).

Set false to disable the sanitization. You can also provide a custom sanitization function.

Default

true

sourcemap?

Type: boolean | "inline" | "hidden"
Optional

Defined in: options/output-options.ts:154

Whether to generate sourcemaps.

false: No sourcemap will be generated.
true: A separate sourcemap file will be generated.
'inline': The sourcemap will be appended to the output file as a data URL.
'hidden': A separate sourcemap file will be generated, but the link to the sourcemap (//# sourceMappingURL comment) will not be included in the output file.

Default

false

sourcemapBaseUrl?

Type: string
Optional

Defined in: options/output-options.ts:160

The base URL for the links to the sourcemap file in the output file.

By default, relative URLs are generated. If this option is set, an absolute URL with that base URL will be generated. This is useful when deploying source maps to a different location than your code, such as a CDN or separate debugging server.

sourcemapDebugIds?

Type: boolean
Optional

Defined in: options/output-options.ts:168

Whether to include debug IDs in the sourcemap.

When true, a unique debug ID will be emitted in source and sourcemaps which streamlines identifying sourcemaps across different builds.

Default

false

sourcemapIgnoreList?

Type: boolean | StringOrRegExp | (relativeSourcePath, sourcemapPath) => boolean
Optional

Defined in: options/output-options.ts:201

Control which source files are included in the sourcemap ignore list.

Files in the ignore list are excluded from debugger stepping and error stack traces.

false: Include no source files in the ignore list
true: Include all source files in the ignore list
string: Files containing this string in their path will be included in the ignore list
RegExp: Files matching this regular expression will be included in the ignore list
function: Custom function to determine if a source should be ignored

Performance

Using static values (boolean, string, or RegExp) is significantly more performant than functions. Calling JavaScript functions from Rust has extremely high overhead, so prefer static patterns when possible.

Type Declaration

boolean

StringOrRegExp

(relativeSourcePath, sourcemapPath) => boolean

Parameters

relativeSourcePath

string

The relative path from the generated .map file to the corresponding source file.

sourcemapPath

string

The fully resolved path of the generated sourcemap file.

Returns

boolean

Example

// ✅ Preferred: Use RegExp for better performance
sourcemapIgnoreList: /node_modules/

// ✅ Preferred: Use string pattern for better performance
sourcemapIgnoreList: "vendor"

// ! Use sparingly: Function calls have high overhead
sourcemapIgnoreList: (source, sourcemapPath) => {
  return source.includes('node_modules') || source.includes('.min.');
}

Default

/node_modules/

sourcemapPathTransform()?

Type: (relativeSourcePath, sourcemapPath) => string
Optional

Defined in: options/output-options.ts:218

A transformation to apply to each path in a sourcemap.

Parameters

relativeSourcePath

string

The relative path from the generated .map file to the corresponding source file.

sourcemapPath

string

The fully resolved path of the generated sourcemap file.

Returns

string

Example

export default defineConfig({
  output: {
    sourcemap: true,
    sourcemapPathTransform: (source, sourcemapPath) => {
      // Remove 'src/' prefix from all source paths
      return source.replace(/^src//, '');
    },
  },
});

topLevelVar?

Type: boolean
Optional

Defined in: options/output-options.ts:632

Whether to use var declarations at the top level scope instead of function / class / let / const expressions.

Enabling this option can improve runtime performance of the generated code in certain environments.

Default

false

In-depth

Multiple JavaScript engines have had and continue to have performance issues with Temporal dead zone (TDZ) checks. These checks validate that a let, const, or class symbol isn't used before it's initialized.

Related issues:

V8: https://issues.chromium.org/issues/42203665
JavaScriptCore: https://bugs.webkit.org/show_bug.cgi?id=199866 (fixed)

virtualDirname?

Type: string
Optional

Defined in: options/output-options.ts:616

Specifies the directory name for "virtual" files that might be emitted by plugins when using preserve modules mode.

Default

'_virtual'

Interface: OutputOptions ​

Properties ​

advancedChunks? ​

groups? ​

includeDependenciesRecursively? ​

Default ​

maxModuleSize? ​

maxSize? ​

minModuleSize? ​

minShareCount? ​

minSize? ​

Example ​

assetFileNames? ​

Default ​

banner? ​

chunkFileNames? ​

Default ​

cleanDir? ​

Default ​

Examples ​

Basic usage ​

Multiple outputs in one config ​

Multiple configurations ​

Different directories in multiple outputs ​

In-depth ​

Execution timing ​

⚠️ Multiple configurations behavior ​

dir? ​

Default ​

dynamicImportInCjs? ​

Default ​

entryFileNames? ​

Default ​

esModule? ​

Default ​

exports? ​

Default ​

extend? ​

Default ​

externalLiveBindings? ​

Default ​

Example ​

file? ​

footer? ​

format? ​

Default ​

generatedCode? ​

globals? ​

Example ​

hashCharacters? ​

Default ​

inlineDynamicImports? ​

Default ​

intro? ​

keepNames? ​

Default ​

legalComments? ​

manualChunks()? ​

Parameters ​

moduleId ​

meta ​

getModuleInfo ​

Returns ​

Deprecated ​

minify? ​

Default ​

minifyInternalExports? ​

Default ​

In-depth ​

name? ​

Example ​

outro? ​

paths? ​

Examples ​

plugins? ​

polyfillRequire? ​

Default ​

postBanner? ​

postFooter? ​

preserveModules? ​

Interface: OutputOptions

Properties

advancedChunks?

groups?

includeDependenciesRecursively?

Default

maxModuleSize?

maxSize?

minModuleSize?

minShareCount?

minSize?

Example

assetFileNames?

Default

banner?

chunkFileNames?

Default

cleanDir?

Default

Examples

Basic usage

Multiple outputs in one config

Multiple configurations

Different directories in multiple outputs

In-depth

Execution timing

⚠️ Multiple configurations behavior

dir?

Default

dynamicImportInCjs?

Default

entryFileNames?

Default

esModule?

Default

exports?

Default

extend?

Default

externalLiveBindings?

Default

Example

file?

footer?

format?

Default

generatedCode?

globals?

Example

hashCharacters?

Default

inlineDynamicImports?

Default

intro?

keepNames?

Default

legalComments?

manualChunks()?

Parameters

moduleId

meta

getModuleInfo

Returns

Deprecated

minify?

Default

minifyInternalExports?

Default

In-depth

name?

Example

outro?

paths?

Examples

plugins?

polyfillRequire?

Default

postBanner?

postFooter?

preserveModules?