Turbopack Is Replacing Webpack: What You Need to Know

TL;DR

Turbopack, written in Rust by the creator of Webpack, is now the default bundler in Next.js for both development and production builds. It delivers dramatically faster build times through incremental computation, but it is not yet a general-purpose Webpack replacement outside the Next.js ecosystem. If you are using Next.js, the migration is largely automatic. If you rely on custom Webpack plugins, expect some adaptation.

What's Happening

Webpack has been the backbone of JavaScript bundling for nearly a decade. It powered the build pipeline for millions of projects and spawned an ecosystem of plugins and loaders that handled everything from CSS modules to SVG optimization. But Webpack's JavaScript-based architecture has reached its performance ceiling, and as projects grow larger, build times measured in minutes become a serious developer experience problem.

Turbopack is the answer from Tobias Koppers, the original creator of Webpack. Built in Rust using the Turbo engine (shared with Turborepo), Turbopack uses an incremental computation model that only recomputes what has changed. Next.js has adopted it as the default bundler, first for development and now for production builds.

The transition is significant. Webpack is not being patched or optimized --- it is being replaced by a fundamentally different architecture designed for the scale of modern web applications.

Why It Matters

Build performance directly impacts developer productivity. Every second you wait for a hot module replacement (HMR) update is a context switch. Every minute you wait for a production build is a minute added to your CI pipeline. For large Next.js applications with hundreds or thousands of modules, the performance difference between Webpack and Turbopack is not incremental --- it is transformational.

For teams maintaining custom Webpack configurations, this transition also means understanding what changes, what breaks, and how to migrate.

How It Works / What's Changed

The Incremental Computation Model

Webpack rebuilds the entire dependency graph on every change. Even with caching, it needs to re-traverse and re-evaluate large portions of the module tree. Turbopack takes a fundamentally different approach inspired by build systems like Bazel and Salsa.

When you change a file, Turbopack:

1. ›Identifies the exact modules affected by the change
2. ›Recomputes only those modules and their direct dependents
3. ›Invalidates only the necessary parts of the output
4. ›Serves the updated result

This means that HMR update speed is roughly constant regardless of project size. A 10-module app and a 10,000-module app both get near-instant updates because the amount of work scales with the change, not with the project.

Using Turbopack in Next.js

In recent Next.js versions, Turbopack is the default. For projects that have not yet updated, you can opt in explicitly:

// next.config.ts
import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  // Turbopack is now the default, but you can configure it explicitly
  turbopack: {
    // Turbopack-specific configuration
    resolveAlias: {
      // Alias configuration (replaces webpack resolve.alias)
      '@components': './src/components',
      '@lib': './src/lib',
    },
  },
};
 
export default nextConfig;

For development:

# Turbopack is the default dev bundler
next dev
 
# To explicitly use Turbopack (older Next.js versions)
next dev --turbopack

For production builds:

# Turbopack production builds
next build

Performance Gains

The performance improvements are most dramatic for large projects. For a Next.js application with approximately 1,000 modules:

Development server startup:
  Webpack:    ~12s
  Turbopack:  ~1.5s

Hot Module Replacement (single file change):
  Webpack:    ~800ms
  Turbopack:  ~50ms

Production build:
  Webpack:    ~45s
  Turbopack:  ~8s

These numbers vary by project complexity, hardware, and the nature of the changes. The key takeaway is not the exact numbers but the order-of-magnitude improvement, especially for HMR where sub-100ms updates make development feel truly instantaneous.

What Works Differently

Turbopack is not a drop-in replacement for Webpack's full feature set. It is purpose-built for Next.js and handles the same use cases through different mechanisms.

CSS Modules work the same way from a developer perspective:

// This works identically with Turbopack
import styles from './Button.module.css';
 
export function Button({ children }: { children: React.ReactNode }) {
  return <button className={styles.button}>{children}</button>;
}

Image optimization continues to use Next.js's built-in image optimization:

import Image from 'next/image';
 
// No bundler-level changes needed
<Image src="/hero.jpg" alt="Hero" width={1200} height={600} />

Environment variables work the same way:

// .env.local
DATABASE_URL=postgresql://localhost:5432/mydb
NEXT_PUBLIC_API_URL=https://api.example.com
 
// Accessible in server components
const dbUrl = process.env.DATABASE_URL;
 
// Accessible in client components (NEXT_PUBLIC_ prefix)
const apiUrl = process.env.NEXT_PUBLIC_API_URL;

What Breaks: Custom Webpack Plugins

The most significant migration concern is custom Webpack plugins. Turbopack does not support the Webpack plugin API. If your next.config.js includes custom Webpack configuration, you need to find alternatives.

Common Webpack customizations and their Turbopack equivalents:

// OLD: Webpack configuration in next.config.js
const oldConfig = {
  webpack: (config) => {
    // SVG as React component
    config.module.rules.push({
      test: /\.svg$/,
      use: ['@svgr/webpack'],
    });
 
    // Custom alias
    config.resolve.alias['@'] = path.resolve(__dirname, 'src');
 
    // Ignore specific modules
    config.plugins.push(new webpack.IgnorePlugin({
      resourceRegExp: /^\.\/locale$/,
      contextRegExp: /moment$/,
    }));
 
    return config;
  },
};
 
// NEW: Turbopack equivalents
const newConfig: NextConfig = {
  turbopack: {
    resolveAlias: {
      '@': './src',
    },
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
    },
  },
};

For Webpack plugins without Turbopack equivalents, you have several options:

1. ›Check if Next.js has a built-in alternative (many common plugins are now framework features)
2. ›Look for a Turbopack-compatible loader
3. ›Move the transformation to a build script that runs before next build

Turbopack's Loader Compatibility

Turbopack supports a subset of Webpack loaders through its rules configuration. This covers many common use cases:

const nextConfig: NextConfig = {
  turbopack: {
    rules: {
      // SVGR for SVG as React components
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
      // GraphQL file support
      '*.graphql': {
        loaders: ['graphql-tag/loader'],
        as: '*.js',
      },
      // YAML support
      '*.yaml': {
        loaders: ['yaml-loader'],
        as: '*.js',
      },
    },
  },
};

Not all Webpack loaders are compatible, but the most commonly used ones work. Loaders that rely on Webpack-specific APIs or modify the compilation process may not work.

Migration Path

For most Next.js projects, migration is straightforward:

1. ›Update Next.js to the latest version
2. ›Remove custom Webpack config and test the build --- many customizations are no longer needed because Next.js handles them natively
3. ›Replace unsupported plugins with Turbopack alternatives or built-in Next.js features
4. ›Test thoroughly --- run your full test suite and verify all pages render correctly
5. ›Check build output --- ensure bundle sizes are comparable and no unexpected assets are missing

# Step-by-step migration
# 1. Update Next.js
npm install next@latest react@latest react-dom@latest
 
# 2. Run development with Turbopack
next dev
 
# 3. Build for production
next build
 
# 4. Compare build output
ls -la .next/static/chunks/

Outside Next.js

Turbopack as a standalone bundler (separate from Next.js) is still in development. If you are using Webpack in a non-Next.js project (a custom React setup, a Vue project, a vanilla JavaScript application), Turbopack is not yet a replacement. For those use cases:

• ›Vite is the most popular Webpack alternative with broad framework support
• ›esbuild is the fastest for simple bundling needs
• ›Rspack is a Webpack-compatible bundler written in Rust that supports most Webpack plugins

My Take

The move from Webpack to Turbopack in Next.js is one of those upgrades where you wonder how you tolerated the old experience. The sub-100ms HMR updates make development feel fundamentally different --- you edit a component, and the change is visible before your eyes move from the editor to the browser.

The transition has been smoother than I expected. For my projects, which use standard Next.js features without exotic Webpack plugins, it was a version upgrade and nothing more. The few projects where I had custom Webpack configuration needed minor adjustments, mostly replacing webpack config blocks with Turbopack-equivalent rules.

My one concern is the ecosystem fragmentation. Webpack's plugin ecosystem was one of its greatest strengths, and Turbopack does not inherit it. For the Next.js use case, this is manageable because Next.js provides built-in alternatives for the most common needs. But if you are relying on niche Webpack plugins, do your compatibility research before upgrading.

The bigger picture is that Rust-based tooling is replacing JavaScript-based tooling across the board: Turbopack for bundling, SWC for transpilation, Biome for linting and formatting. The performance gains from native code are too significant to ignore, and the developer experience improvements are substantial.

What This Means for You

If you are using Next.js: Update to the latest version and let Turbopack handle your builds. The performance improvement is free and immediate for most projects.

If you have custom Webpack configuration in Next.js: Audit your webpack config blocks. Most can be replaced with Turbopack rules or built-in Next.js features. Test your build thoroughly after migrating.

If you are not using Next.js: Turbopack is not yet relevant to you. Consider Vite or Rspack as Webpack alternatives with broader framework support.

If you maintain Webpack plugins: Evaluate whether your plugin's functionality is still needed or has been absorbed by framework-level features. If it is still needed, consider porting to Turbopack's loader format or Rspack's Webpack-compatible plugin API.

FAQ

Is Turbopack a drop-in replacement for Webpack?

In Next.js yes, it handles the same configuration automatically. Standalone Turbopack outside Next.js is still in development and not yet a general Webpack replacement.

How much faster is Turbopack than Webpack?

Turbopack is roughly 10x faster for large projects due to its Rust engine and incremental computation that only recomputes what changed.

Do Webpack plugins work with Turbopack?

No, Webpack plugins are not compatible. Turbopack has its own plugin system, and Next.js has built-in alternatives for the most common Webpack plugins.