Fix: This build is using Turbopack with a webpack config and no turbopack config

The warning

You upgraded to Next.js 16. You ran next build. And instead of a clean build you got this:

⚠ This build is using Turbopack with a webpack config and no turbopack config.
  Your webpack config will be ignored. To configure Turbopack, use turbopack in next.config.

So your build might still work but whatever you had in your webpack config is being silently ignored. Maybe that was a custom loader for SVGs. Maybe it was a plugin for handling markdown. Maybe it was an alias you set up months ago and forgot about. Whatever it was, Turbopack does not care. It is not reading your webpack config and it is not going to.

This caught a lot of people off guard because Next.js 16 made Turbopack the default bundler. If you had a next.config.js with a webpack function it just gets skipped now. No error, no crash, just silence. Which is honestly worse than an error because you do not realize your config is being ignored until something breaks in production.

Why this happens

Next.js used webpack for years. Your next.config.js could export a webpack function that let you customize the webpack config directly:

// next.config.js
/** @type {import('next').NextConfig} */
module.exports = {
  webpack(config) {
    config.module.rules.push({
      test: /\.svg$/,
      use: ['@svgr/webpack']
    })
    return config
  }
}

Turbopack is written in Rust and has its own configuration format. It does not understand webpack plugins, webpack loaders, or webpack rules. When Next.js 16 switched to Turbopack by default it could not just translate your webpack config automatically. So it prints a warning and moves on.

The warning is actually polite compared to what could happen. I have seen people miss it entirely because it scrolls by fast in CI output and the build still exits with code 0. Then they deploy and their SVG imports break or their aliases stop working and they spend two hours figuring out why.

How to fix it

You have two options and they depend on what your webpack config was doing.

Option A: Migrate to the turbopack config

Next.js 16 added a turbopack key to next.config.js. This is where you put Turbopack-specific configuration. The API is smaller than webpack's but covers the common cases.

Here is the SVG loader example migrated:

// next.config.js
/** @type {import('next').NextConfig} */
module.exports = {
  turbopack: {
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js'
      }
    }
  }
}

The structure is different from webpack. Instead of pushing rules into an array you define them as an object keyed by file pattern. The as field tells Turbopack what the output type should be.

Here is another common case. If you had webpack resolve aliases:

// Old webpack config
module.exports = {
  webpack(config) {
    config.resolve.alias['@components'] = path.resolve(__dirname, 'components')
    return config
  }
}

The Turbopack equivalent:

// next.config.js
module.exports = {
  turbopack: {
    resolveAlias: {
      '@components': path.resolve(__dirname, 'components')
    }
  }
}

For extensions (like importing files without the extension):

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

Option B: Opt out of Turbopack and keep using webpack

If your webpack config is complex and uses plugins that have no Turbopack equivalent, you can stay on webpack for now. This is fine. Turbopack is the default but webpack is still there.

# Use webpack for builds
next build --webpack

Or in your package.json:

{
  "scripts": {
    "build": "next build --webpack",
    "dev": "next dev --webpack"
  }
}

Or in the config file:

// next.config.js
module.exports = {
  // Use webpack for both dev and build
  devIndicators: false
}

Wait, that is not right. The correct way to force webpack in the config is:

// next.config.js
/** @type {import('next').NextConfig} */
module.exports = {
  // No direct config flag, use the CLI flag instead
  // next build --webpack
}

Actually the cleanest way is the CLI flag. There is no stable config-level toggle for this in Next.js 16 yet. Just use --webpack in your scripts and move on. You are not losing anything by staying on webpack for a release cycle while you migrate your config piece by piece.

Common things that break

Here are the webpack configs I see most often in the wild and their Turbopack equivalents.

Custom file loaders (images, fonts, etc)

// Webpack version
module.exports = {
  webpack(config) {
    config.module.rules.push({
      test: /\.(png|jpg|gif)$/,
      use: { loader: 'file-loader' }
    })
    return config
  }
}

// Turbopack version
// You probably do not need this. Next.js handles these
// file types natively. Just import the file directly:
// import img from './photo.png'
// Next.js will optimize it automatically.

Markdown processing

// Webpack version
module.exports = {
  webpack(config) {
    config.module.rules.push({
      test: /\.md$/,
      use: 'raw-loader'
    })
    return config
  }
}

// Turbopack version
module.exports = {
  turbopack: {
    rules: {
      '*.md': {
        loaders: ['raw-loader'],
        as: '*.js'
      }
    }
  }
}

Environment injection via DefinePlugin

// Webpack version
const webpack = require('webpack')

module.exports = {
  webpack(config) {
    config.plugins.push(
      new webpack.DefinePlugin({
        'process.env.CUSTOM_VAR': JSON.stringify('value')
      })
    )
    return config
  }
}

// Turbopack: just use a .env file instead
// .env.local
// CUSTOM_VAR=value
// Next.js exposes it automatically

Honestly if you were using DefinePlugin you should switch to .env files anyway. That is the Next.js way and it works with both bundlers.

How to know if you missed something

The warning tells you that your webpack config is being ignored. But it does not tell you what inside that config will break. Here is a quick audit process.

Open your next.config.js
Find the webpack function
List every rule, plugin, and alias it sets up
For each one, check if you have a Turbopack equivalent in the turbopack key
If you do not have an equivalent, decide: migrate to Turbopack or stick with webpack

Most configs are small. I have seen maybe five or six rules in the most complex ones. It is usually not a huge migration. The ones that hurt are custom webpack plugins that do code transformation. Those have no Turbopack equivalent and you either rewrite them as a separate build step or stay on webpack.

What I would do

If I were starting fresh I would use Turbopack and never look back. It is faster and the config is simpler. But if you have an existing project with a working webpack config, do not rush the migration. Add --webpack to your scripts, get your build green, then migrate one rule at a time. The warning is annoying but it is not going to break your app. Silently ignoring your config is what breaks your app, so either fix it or opt out.

I fix Next.js production issues for a living. If your build broke after upgrading to Next.js 16 and you need help sorting out the Turbopack migration, email me.