#output.target

• Type:

type RsbuildTarget = 'web' | 'node' | 'web-worker';

• Default: 'web'

Sets the build target for Rsbuild.

Rsbuild supports multiple build targets for running in different environments. After setting the target type, Rsbuild's default configuration will change accordingly.

#Default target

The target is 'web' by default, building outputs for browsers.

Rsbuild reads the Browserslist config in the project to determine the range of supported browsers.

#Optional values

In addition to 'web', target can also be set to the following values:

• 'node': Build for Node.js environment, usually used in SSR or other scenarios.
• 'web-worker': Build for Web Workers environment.

For example, to build for the Node.js environment:

export default {
  output: {
    target: 'node',
  },
};

#Parallel builds

You can use environments to build multiple targets in parallel.

To build web and node outputs simultaneously, use environments:

export default {
  environments: {
    web: {
      output: {
        target: 'web',
        distPath: {
          root: 'dist/client',
        },
      },
    },
    node: {
      output: {
        target: 'node',
        distPath: {
          root: 'dist/server',
        },
      },
    },
  },
};

#Node target

Refers to the build target for running in the Node.js environment, usually used in scenarios such as SSR.

When target is set to 'node', Rsbuild will:

• Set Rspack's target to 'node'.
• No HTML files will be generated, and HTML-related logic will not be executed, since HTML is not required in the Node.js environment.
• The default code split strategy will be disabled, but dynamic import can still work.
• Disable HMR.
• Set the default value of Browserslist to ['node >= 20'].
• Set the default value of output.emitCss to false. This means CSS code will not be extracted to separate files, but CSS Modules id information will be included in the bundle.

#Node addons

When target is set to 'node', Rsbuild allows you to import Node.js Addons in JavaScript files.

For example:

import addon from './addon.node';

addon.doSomething();

The referenced addons file will be output to the dist directory:

dist/index.js
dist/addon.node

#Web Workers target

Refers to the build target for running in the Web Worker environment.

When target is set to 'web-worker', Rsbuild will:

• Set Rspack's target to 'webworker'.
• No HTML files will be generated, and HTML-related logic will not be executed, since HTML is not required in the Web Worker environment.
• CSS code will not be bundled or extracted, but CSS Modules id information will be included in the bundle (the default value of output.emitCss is false).
• Disable chunk splitting by default. Modules referenced by import() are included in the bundle without generating separate async chunks.
• Set the default value of output.emitCss to false. This means CSS code will not be extracted to separate files, but CSS Modules id information will be included in the bundle.
• Disable HMR.

For more information, see Using Web Workers.

#Other targets

For other runtimes, choose the closest built-in target and adapt it with additional configuration or plugins.

#Electron

Rspack supports other target types, such as electron-main and electron-renderer.

Rsbuild currently does not support these targets. You can configure these targets using tools.rspack.

For example, setting the target to 'electron-main' will override the default 'web' set by Rsbuild.

export default {
  tools: {
    rspack: {
      target: 'electron-main',
    },
  },
};

#Cloudflare Workers

Cloudflare Workers use a default export for event handlers and named exports for classes such as Durable Objects. To build this type of Worker, enable output.module to generate ES module output and configure Rspack's output.library.type to preserve the entry exports.

The following configuration builds an ES module Worker with the default chunk splitting settings:

export default {
  output: {
    target: 'web-worker',
    module: true,
  },
  tools: {
    rspack: {
      output: {
        library: { type: 'module' },
      },
    },
  },
};

This configuration covers bundling. Use Wrangler or a platform plugin for local development and deployment. See Deploying to Cloudflare Workers.

#Built-in modules

Built-in modules such as cloudflare:workers and cloudflare:sockets are provided by the Cloudflare Workers runtime. When importing these modules, use output.externals to exclude them from the bundle and preserve them as ES module imports loaded at runtime:

export default {
  output: {
    externals: [/^cloudflare:/],
  },
};

If your code or dependencies also import Node.js built-in modules, add /^node:/ to externalize imports such as node:buffer:

export default {
  output: {
    externals: [/^cloudflare:/, /^node:/],
  },
};

Make sure the Node.js APIs you use are supported and enabled in your Worker. Configuring externals does not provide polyfills. See Cloudflare's Node.js compatibility documentation.

The /^node:/ rule does not match imports without the node: prefix. For example, when importing buffer, add { buffer: 'node:buffer' } to the externals array to map it to node:buffer.

#Conditional exports

Some dependencies, such as postgres, use the workerd export condition to provide an entry for Cloudflare Workers. Add workerd to resolve.conditionNames to use these entries:

export default {
  resolve: {
    conditionNames: ['workerd', '...'],
  },
};

The '...' value keeps the default conditions enabled.