How to Fix: Can’t configure turbopack in next.config.ts file

Turbopack configuration fails in next.config.ts because the config format is stricter than many examples written for webpack, and mixing unsupported shapes, legacy keys, or plugin-style loader assumptions can break type checking or runtime config parsing immediately.

Understanding the Root Cause

In this issue, the problem usually appears right after adding @svgr/webpack and then trying to configure Turbopack inside next.config.ts. The important detail is that Turbopack does not consume webpack configuration the same way webpack does.

With webpack, you commonly extend config using a webpack(config) { ... } function and push custom loader rules. That pattern works for the classic webpack bundler, but Turbopack uses its own configuration model. If you try to express Turbopack behavior with webpack-only assumptions, or if you put the config under the wrong key or wrong structure, Next.js cannot validate it correctly.

Another source of confusion is the file type: next.config.ts is type-checked. That means invalid config shapes are caught earlier than in a loosely typed JavaScript config. So a setup that looks close to correct may still fail because:

• the turbopack key is missing or malformed,
• the rules object is using an unsupported shape,
• @svgr/webpack is referenced the way webpack expects, but not the way Turbopack expects,
• or the project is trying to combine webpack and Turbopack config as if they were interchangeable.

For SVG handling specifically, the fix is to configure Turbopack rules explicitly for *.svg instead of only relying on the traditional webpack extension hook.

Step-by-Step Solution

The safest fix is to define a valid Next.js config object and place the Turbopack loader rule under the correct key.

1. Install the SVG loader

npm install @svgr/webpack

2. Update next.config.ts

Use a typed config and define a Turbopack rule for SVG files:

import type { NextConfig } from 'next'

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

export default nextConfig

This is the key point: Turbopack rules are declared declaratively. You do not mutate a webpack config object here.

3. Import SVGs as React components

import Logo from './logo.svg'

export default function Page() {
  return <Logo />
}

4. Start the app with Turbopack enabled

next dev --turbopack

Or in package.json:

{
  "scripts": {
    "dev": "next dev --turbopack"
  }
}

5. If you still need webpack fallback behavior, keep it separate

If your project also runs without Turbopack in some environments, you can keep a webpack rule too, but understand that it is for the webpack bundler only:

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  turbopack: {
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
    },
  },
  webpack(config) {
    config.module.rules.push({
      test: /\.svg$/i,
      use: ['@svgr/webpack'],
    })
    return config
  },
}

export default nextConfig

This dual setup is helpful during migration, but the critical lesson is that the webpack section does not configure Turbopack.

6. Verify your Next.js version

Turbopack support evolves quickly. If the config still errors, upgrade to a recent Next.js release:

npm install next@latest react@latest react-dom@latest

You can also review the official framework documentation via the Next.js docs and Turbopack-specific configuration guidance through the next.config reference.

Common Edge Cases

• Using the wrong glob key: Turbopack rules should target patterns like '*.svg'. If you use a webpack-style regex directly in the Turbopack section, it may not validate or behave as expected.
• Forgetting the as output mapping: SVG transformed by @svgr/webpack should be emitted as JavaScript, so as: '*.js' is often required for correct module handling.
• Importing SVG as a URL and as a component interchangeably: If one part of the app expects a file path while another expects a React component, you may see confusing module errors.
• Old examples from webpack-only setups: Many blog posts show only webpack(config) customization. That does not solve the Turbopack path.
• TypeScript config errors: In next.config.ts, invalid property names or wrong object shapes are surfaced faster. Typing the config with NextConfig helps catch mistakes early.
• Version mismatch: If Next.js, React, and loader packages are outdated or incompatible, config that is valid in newer releases may still fail locally.

FAQ

Can I configure SVG support only through the webpack function?

Yes, but only for the webpack bundler. If you run Turbopack, you must add the corresponding turbopack.rules entry.

Why does this fail more often in next.config.ts than next.config.js?

Because TypeScript checks the config structure. Wrong keys, invalid nesting, and unsupported shapes are easier to catch in next.config.ts.

Do I need both webpack and turbopack config sections?

Only if your project needs to support both bundlers. If you always run with Turbopack, the turbopack section is the important one for this issue.

The practical fix is simple: do not treat Turbopack like webpack. Define SVG handling under turbopack.rules, keep the shape valid for next.config.ts, and use @svgr/webpack as a loader within that Turbopack rule.