Skip to content

Interface: OutputOptions

Properties

advancedChunks?

  • Type: optional advancedChunks: object

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

groups?

Groups to be used for advanced chunking.

includeDependenciesRecursively?

  • Type: optional includeDependenciesRecursively: boolean

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

to avoid generating invalid chunks.

Default
ts
true

maxModuleSize?

  • Type: optional maxModuleSize: number

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

maxSize?

  • Type: optional maxSize: number

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

minModuleSize?

  • Type: optional minModuleSize: number

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

minShareCount?

  • Type: optional minShareCount: number

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

minSize?

  • Type: optional minSize: number

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

Example

Basic vendor chunk

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

Multiple chunk groups with priorities

js
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

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

assetFileNames?

  • Type: optional assetFileNames: string | (chunkInfo) => string

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.

See also output.chunkFileNames, output.entryFileNames.

Default

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

  • Type: optional banner: string | (chunk) => string | Promise<string>

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: optional chunkFileNames: string | (chunkInfo) => string

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.

See also output.assetFileNames, output.entryFileNames.

Default

ts
'[name]-[hash].js'

cleanDir?

  • Type: optional cleanDir: boolean

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

Default

false

Examples

Basic usage
js
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:

js
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:

js
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:

js
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: optional dir: string

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

ts
'dist'

dynamicImportInCjs?

  • Type: optional dynamicImportInCjs: boolean

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

ts
true

entryFileNames?

  • Type: optional entryFileNames: string | (chunkInfo) => string

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.

See also output.assetFileNames, output.chunkFileNames.

Default

ts
'[name].js'

esModule?

  • Type: optional esModule: boolean | "if-default-prop"

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

ts
'if-default-prop'

exports?

  • Type: optional exports: "auto" | "named" | "default" | "none"

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:

js
// 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:

js
// 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:

js
// 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

ts
'auto'

extend?

  • Type: optional extend: boolean

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

ts
false

externalLiveBindings?

  • Type: optional externalLiveBindings: boolean

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

js
// input
export { x } from 'external';
js
// CJS output with externalLiveBindings: true
var external = require('external');

Object.defineProperty(exports, 'x', {
  enumerable: true,
  get: function () {
    return external.x;
  },
});
js
// CJS output with externalLiveBindings: false
var external = require('external');

exports.x = external.x;

file?

  • Type: optional file: string

The file path for the single generated chunk.

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


  • Type: optional footer: string | (chunk) => string | Promise<string>

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: optional format: "es" | "cjs" | "esm" | "module" | "commonjs" | "iife" | "umd"

Expected format of generated code.

Default

ts
'esm'

generatedCode?

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: optional globals: Record<string, string> | (name) => string

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

Example

js
export default defineConfig({
  external: ['jquery'],
  output: {
    format: 'iife',
    name: 'MyBundle',
    globals: {
      jquery: '$',
    }
  }
});
js
// input
import $ from 'jquery';
js
// output
var MyBundle = (function ($) {
  // ...
})($);

hashCharacters?

  • Type: optional hashCharacters: "base64" | "base36" | "hex"

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

ts
'base64'

inlineDynamicImports?

  • Type: optional inlineDynamicImports: boolean

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

ts
false

intro?

  • Type: optional intro: string | (chunk) => string | Promise<string>

A string to prepend inside any format-specific wrapper.

See output.banner, output.postBanner as well.


keepNames?

  • Type: optional keepNames: boolean

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

ts
false

legalComments?

  • Type: optional legalComments: "none" | "inline"

Control comments in the output.

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

manualChunks()?

  • Type: optional manualChunks: (moduleId, meta) => string | NullValue

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

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

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

will be transformed to

js
{
  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

meta
getModuleInfo

(moduleId) => ModuleInfo | null

Returns

string | NullValue

Deprecated

Please use output.advancedChunks instead.

WARNING

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


minify?

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

ts
false

minifyInternalExports?

  • Type: optional minifyInternalExports: boolean

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:

js
// 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:

js
// 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:

js
// 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: optional name: string

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

Example

js
export default defineConfig({
  output: {
    format: 'iife',
    name: 'MyBundle',
  }
});
js
// 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.

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

outro?

  • Type: optional outro: string | (chunk) => string | Promise<string>

A string to append inside any format-specific wrapper.

See output.footer, output.postFooter as well.


paths?

  • Type: optional paths: Record<string, string> | (id) => string

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

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

plugins?

  • Type: optional plugins: RolldownOutputPluginOption

The list of plugins to use only for this output.


polyfillRequire?

  • Type: optional polyfillRequire: boolean

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

ts
true

postBanner?

  • Type: optional postBanner: string | (chunk) => string | Promise<string>

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

See output.banner, output.intro as well.


postFooter?

  • Type: optional postFooter: string | (chunk) => string | Promise<string>

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

See output.footer, output.outro as well.


preserveModules?

  • Type: optional preserveModules: boolean

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:

js
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

ts
false

preserveModulesRoot?

  • Type: optional preserveModulesRoot: string

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

js
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: optional sanitizeFileName: boolean | (name) => string

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

ts
true

sourcemap?

  • Type: optional sourcemap: boolean | "inline" | "hidden"

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

ts
false

sourcemapBaseUrl?

  • Type: optional sourcemapBaseUrl: string

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: optional sourcemapDebugIds: boolean

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

ts
false

sourcemapIgnoreList?

  • Type: optional sourcemapIgnoreList: boolean | StringOrRegExp | (relativeSourcePath, sourcemapPath) => boolean

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

js
// ✅ 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

ts
/node_modules/

sourcemapPathTransform()?

  • Type: optional sourcemapPathTransform: (relativeSourcePath, sourcemapPath) => string

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

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

topLevelVar?

  • Type: optional topLevelVar: boolean

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:


virtualDirname?

  • Type: optional virtualDirname: string

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

Default

ts
'_virtual'

Released under the MIT License.