turbopack

The turbopack option lets you customize Turbopack to transform different files and change how modules are resolved.

Good to know: The turbopack option was previously named experimental.turbo in Next.js versions 13.0.0 to 15.2.x, an option which still works as an alias, but new configuration should use the top-level turbopack option.

If you are using an older version of Next.js, run npx @next/codemod@latest next-experimental-turbo-to-turbopack . to automatically migrate your configuration.

import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  turbopack: {
    // ...
  },
}
 
export default nextConfig

Good to know:

• Turbopack for Next.js does not require loaders or loader configuration for built-in functionality. Turbopack has built-in support for CSS and compiling modern JavaScript, so there's no need for css-loader, postcss-loader, or babel-loader if you're using @babel/preset-env.

Reference

Options

The following options are available for the turbopack configuration:

Supported loaders

The following loaders have been tested to work with Turbopack's webpack loader implementation, but many other webpack loaders should work as well even if not listed here:

• babel-loader (Configured automatically if a Babel configuration file is found)
• @svgr/webpack
• svg-inline-loader
• yaml-loader
• string-replace-loader
• raw-loader
• sass-loader (Configured automatically)
• graphql-tag/loader

Missing Webpack loader features

Turbopack uses the loader-runner library to execute webpack loaders, which provides most of the standard loader API. However, some features are not supported:

Module loading:

• importModule - No support
• loadModule - No support

File system and output:

• fs - Partial support: only fs.readFile is currently implemented.
• emitFile - No support

Utilities:

• utils - No support

If you have a loader that is critically dependent upon one of these features please file an issue.

Examples

Root directory

Turbopack uses the root directory to resolve modules. Files outside of the project root are not resolved.

Files are not resolved outside of the project root is to improve cache validation, reduce filesystem watching overhead, and reduce the number of resolving steps needed.

Next.js automatically detects the root directory of your project. It does so by looking for one of these files:

• pnpm-lock.yaml
• package-lock.json
• yarn.lock
• bun.lock
• bun.lockb

If you have a different project structure, for example if you don't use workspaces, you can manually set the root option:

const path = require('path')
module.exports = {
  turbopack: {
    root: path.join(__dirname, '..'),
  },
}

To resolve files from linked dependencies outside the project root (e.g. npm link), you must either configure the turbopack.root to the parent directory of both the project and the linked dependencies or configure an additional root.

Use this option to configure the root when working in a monorepo. Do not extend the root directory too broadly (e.g. to your home directory). Turbopack may watch all files inside of roots, and configuring too broad of a root directory can cause significant performance problems.

Additional roots (experimental)

experimental.turbopackAdditionalRoots allows Turbopack to follow symbolic links whose targets are outside turbopack.root.

It is useful for linked packages that live outside the project (e.g. npm link or a global virtual store).

Additional roots can only be crossed at symlink boundaries. Direct relative imports that escape a root are unsupported.

const path = require('path')
 
module.exports = {
  experimental: {
    turbopackAdditionalRoots: {
      linkedPackages: { path: path.join(__dirname, '../packages') },
    },
  },
}

Each key identifies one root. path can be absolute or relative to the directory where you run Next.js.

Good to know:

• The symbolic link and its target must both be available on the build machine before next dev or next build starts.
• Deployment tools and CI systems may copy your repository to a separate build machine. These tools may be unaware of the additional roots, and they may fail to copy required files.
• On Windows, builds require Developer Mode or elevated permissions to create symbolic links. Creating output artifacts may require creating symbolic links. In some cases, Turbopack can fall back to directory junctions when symlink creation is not permitted, but these junctions use absolute paths, so the resulting output may not be relocatable.

If a root path is not found when next build or next dev starts, a warning will be issued, unless ignoreIfMissing is set to true (defaults to false).

To ensure portability of your configuration across a variety of platforms, including Windows, a root name must meet all of these requirements:

• It contains 1 to 40 characters.
• Each character must be an ASCII letter (a-z or A-Z), a digit (0-9), an underscore (_), or a hyphen (-).
• It is not a Windows device name.
• It does not duplicate an earlier name under ASCII case-insensitive comparison.

To avoid ambiguous references to files, additional roots may not overlap turbopack.root or one another. This means an additional root cannot be inside turbopack.root or contain it. For example, configuring both foo/ and foo/bar/ as additional roots would produce a warning, and the overlapping additional root will be ignored.

Additional roots change Next.js's trace format.

When using output: "standalone", unbundled files stored in these additional roots will be copied to a subdirectory of the output directory containing the configured name of the root.

Configuring webpack loaders

If you need loader support beyond what's built in, many webpack loaders already work with Turbopack. There are currently some limitations:

• Only a core subset of the webpack loader API is implemented. Currently, there is enough coverage for some popular loaders, and we'll expand our API support in the future.
• Only loaders that return JavaScript code are supported. Loaders that transform files like stylesheets or images are not currently supported.
• Options passed to webpack loaders must be plain JavaScript primitives, objects, and arrays. For example, it's not possible to pass require() plugin modules as option values.

To configure loaders, add the names of the loaders you've installed and any options in next.config.js, mapping file extensions to a list of loaders. Rules are evaluated in order.

Here is an example below using the @svgr/webpack loader, which enables importing .svg files and rendering them as React components.

module.exports = {
  turbopack: {
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
    },
  },
}

Good to know: Globs used in the rules object match based on file name, unless the glob contains a / character, which will cause it to match based on the full project-relative file path. Windows file paths are normalized to use unix-style / path separators.

Turbopack uses a modified version of the Rust globset library.

For loaders that require configuration options, you can use an object format instead of a string:

module.exports = {
  turbopack: {
    rules: {
      '*.svg': {
        loaders: [
          {
            loader: '@svgr/webpack',
            options: {
              icon: true,
            },
          },
        ],
        as: '*.js',
      },
    },
  },
}

Good to know: Prior to Next.js version 13.4.4, turbopack.rules was named turbo.loaders and only accepted file extensions like .mdx instead of *.mdx.

Advanced webpack loader conditions

You can further restrict where a loader runs using the advanced condition syntax:

module.exports = {
  turbopack: {
    rules: {
      // '*' will match all file paths, but we restrict where our
      // rule runs with a condition.
      '*': {
        condition: {
          all: [
            // 'foreign' is a built-in condition.
            { not: 'foreign' },
            // 'path' can be a RegExp or a glob string. A RegExp matches
            // anywhere in the full project-relative file path.
            { path: /^img\/[0-9]{3}\// },
            {
              any: [
                { path: '*.svg' },
                // 'query' matches anywhere in the full query string,
                // which can be empty, or start with `?`.
                { query: /[?&]svgr(?=&|$)/ },
                // 'content' is always a RegExp, and can match
                // anywhere in the file.
                { content: /\<svg\W/ },
              ],
            },
          ],
        },
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
    },
  },
}

• Supported boolean operators are {all: [...]}, {any: [...]} and {not: ...}.
• Supported customizable operators are {path: string | RegExp}, {content: RegExp}, {query: string | RegExp}, and {contentType: string | RegExp}. If multiple operators are specified in the same object, it acts as an implicit and.
  • path matches against the project-relative file path. A string is treated as a glob pattern, while a RegExp can be used to match the path partially.
  • content matches anywhere in the file content.
  • query matches the import's query string (e.g., ?foo in import './file?foo'). A string must match exactly, while a RegExp can be used to match the query string partially.
  • contentType matches the MIME content type of the resource (e.g., from data URLs like data:text/plain,...). A string is treated as a glob pattern (e.g., text/*, image/*), while a RegExp can be used to match the content type partially.

In addition, a number of built-in conditions are supported:

• browser: Matches code that will execute on the client. Server code can be matched using {not: 'browser'}.
• foreign: Matches code in node_modules, as well as some Next.js internals. Usually you'll want to restrict loaders to {not: 'foreign'}. This can improve performance by reducing the number of files the loader is invoked on.
• development: Matches when using next dev.
• production: Matches when using next build.
• node: Matches code that will run on the default Node.js runtime.
• edge-light: Matches code that will run on the Edge runtime (deprecated).

Rules can be an object or an array of objects. An array is often useful for modeling disjoint conditions:

module.exports = {
  turbopack: {
    rules: {
      '*.svg': [
        {
          condition: 'browser',
          loaders: ['@svgr/webpack'],
          as: '*.js',
        },
        {
          condition: { not: 'browser' },
          loaders: [require.resolve('./custom-svg-loader.js')],
          as: '*.js',
        },
      ],
    },
  },
}

Good to know: All matching rules are executed in order.

Module types

You can set the module type directly without using a loader. This is useful for changing how files are processed, similar to webpack's type option.

module.exports = {
  turbopack: {
    rules: {
      '*.svg': {
        type: 'asset',
      },
    },
  },
}

When using type: 'asset', importing the file returns its URL:

import svgUrl from './icon.svg'
 
export default function Page() {
  return <img src={svgUrl} alt="Icon" />
}

The type option can be combined with loaders - loaders run first, then the result is processed according to the specified type.

Available module types:

Inline loader configuration with import attributes

You can apply a Turbopack loader to an individual import using the with clause (import attributes). This is specified per-import rather than globally via turbopack.rules.

This is useful when you want to apply a loader to a specific import without affecting all files of that type.

// Apply a raw loader to import a .txt file as a JavaScript module
import rawText from '../data.txt' with { turbopackLoader: 'raw-loader', turbopackAs: '*.js' }
 
export default function Page() {
  return <p>{rawText}</p>
}

The following import attributes are supported:

Loaders with options pass a JSON-encoded string via turbopackLoaderOptions:

import value from '../data.js' with { turbopackLoader: 'string-replace-loader', turbopackLoaderOptions: '{"search":"PLACEHOLDER","replace":"replaced value"}' }

Good to know: Import attributes with turbopackLoader are Turbopack-specific and are not supported by webpack. This feature requires the with keyword (not assert) in your import statements.

Resolving aliases

Turbopack can be configured to modify module resolution through aliases, similar to webpack's resolve.alias configuration.

To configure resolve aliases, map imported patterns to their new destination in next.config.js:

module.exports = {
  turbopack: {
    resolveAlias: {
      underscore: 'lodash',
      mocha: { browser: 'mocha/browser-entry.js' },
    },
  },
}

This aliases imports of the underscore package to the lodash package. In other words, import underscore from 'underscore' will load the lodash module instead of underscore.

Turbopack also supports conditional aliasing through this field, similar to Node.js' conditional exports. At the moment only the browser condition is supported. In the case above, imports of the mocha module will be aliased to mocha/browser-entry.js when Turbopack targets browser environments.

Resolving custom extensions

Turbopack can be configured to resolve modules with custom extensions, similar to webpack's resolve.extensions configuration.

To configure resolve extensions, use the resolveExtensions field in next.config.js:

module.exports = {
  turbopack: {
    resolveExtensions: [
      '.mdx',
      '.tsx',
      '.ts',
      '.jsx',
      '.js',
      '.mjs',
      '.node',
      '.json',
    ],
  },
}

This overwrites the default resolve extensions with the provided list, so include every extension you still need. The defaults are .tsx, .ts, .jsx, .js, .mjs, and .json, and server-side resolution adds .node for native modules. Listing .node on the client is harmless, so a single list can cover both.

Good to know: This applies to your own source files. Imports resolved inside node_modules keep their own extension list and are not affected by this option.

For more information and guidance for how to migrate your app to Turbopack from webpack, see Turbopack's documentation on webpack compatibility.

Debug IDs

Turbopack can be configured to generate debug IDs in JavaScript bundles and source maps.

To configure debug IDs, use the debugIds field in next.config.js:

module.exports = {
  turbopack: {
    debugIds: true,
  },
}

The option automatically adds a polyfill for debug IDs to the JavaScript bundle to ensure compatibility. The debug IDs are available in the globalThis._debugIds global variable.

Version History