DEV Community

HK Lee
HK Lee

Posted on • Originally published at pockit.tools

Turbopack in 2026: The Complete Guide to Next.js's Rust-Powered Bundler

#turbopack #nextjs #webpack #rust

If you've updated to Next.js 16 recently, you've probably noticed something different. Your dev server starts in under a second. Hot Module Replacement (HMR) updates happen before you can blink. And here's the big change: Turbopack is now the default bundler—no flags needed.

Welcome to the new era of JavaScript bundling.

Turbopack has been cooking since 2022 when Vercel announced it as "the successor to Webpack." After years of development, it hit stable for dev in Next.js 15, and with Next.js 16 (October 2025), it became the default bundler for all applications. The latest Next.js 16.1 (December 2025) added stable File System Caching, making it even faster.

Let's find out.

What Is Turbopack?

Turbopack is a Rust-based JavaScript/TypeScript bundler built by Vercel, designed specifically for Next.js but with plans to become framework-agnostic. It's not a drop-in replacement for Webpack—it's a ground-up rewrite that rethinks how bundling should work in 2026.

The Problem with Webpack

Webpack revolutionized JavaScript bundling when it launched in 2012. But it was designed for a different era:

  • Projects had hundreds of files, not tens of thousands
  • Node.js was the only runtime option
  • TypeScript and JSX weren't mainstream
  • HMR was a nice-to-have, not a requirement

Fast forward to 2026, and Webpack's architecture is showing its age:

# Typical Next.js 14 project with Webpack
Cold start: 12-45 seconds
HMR update: 1-5 seconds
Full rebuild: 30-120 seconds
Enter fullscreen mode Exit fullscreen mode

The problem isn't Webpack's fault—it's that JavaScript is fundamentally slow for compute-heavy tasks like bundling. No amount of optimization can overcome V8's performance ceiling.

The Rust Advantage

Turbopack is written in Rust, which gives it several advantages:

  1. Native Performance: Rust compiles to machine code, eliminating V8 overhead
  2. True Parallelism: Rust's ownership model enables safe multi-threading without the GC pauses
  3. Memory Efficiency: Manual memory management means no garbage collection spikes
  4. Incremental by Design: Rust's type system makes it easier to build correct incremental computation

But Rust alone isn't the secret sauce. Turbopack introduces a fundamentally different architecture.

The Turbo Engine

At Turbopack's core is the "Turbo Engine," a memoization and incremental computation system. Think of it as a smart cache that:

  1. Remembers everything: Every function call result is cached
  2. Tracks dependencies: It knows which outputs depend on which inputs
  3. Invalidates minimally: When a file changes, only affected computations are re-run 
Traditional bundler:
  File changed → Rebuild entire bundle → Ship to browser

Turbopack:
  File changed → Recompute only affected modules → Send delta to browser
Enter fullscreen mode Exit fullscreen mode

This is why HMR with Turbopack feels instantaneous—it's literally doing less work.

Performance Benchmarks

Let's get into the numbers. These benchmarks were run on a real-world Next.js 15 e-commerce application.

Test Environment

  • Project: 2,847 TypeScript files, 156 React components
  • Hardware: M3 MacBook Pro, 36GB RAM
  • Node.js: v22.1.0
  • Next.js: 16.1.0

Cold Start (Dev Server)

Bundler Time vs Turbopack
Webpack 5 18.4s 23x slower
Turbopack 0.8s baseline

Hot Module Replacement

Bundler Time vs Turbopack
Webpack 5 1.2s 60x slower
Turbopack 20ms baseline

Page Compilation (New Route)

Bundler Time vs Turbopack
Webpack 5 3.1s 15x slower
Turbopack 0.2s baseline

Memory Usage (Dev Server Running)

Bundler RAM vs Turbopack
Webpack 5 1.8GB 1.5x more
Turbopack 1.2GB baseline

The numbers don't lie. Turbopack is dramatically faster for development workflows.

Getting Started with Turbopack

Enabling Turbopack

In Next.js 16+, Turbopack is enabled by default—no configuration needed. Just run:

# Turbopack is now the default!
next dev

# If you're on older Next.js 15.x, use:
next dev --turbopack
Enter fullscreen mode Exit fullscreen mode

Verifying It's Working

You'll see confirmation in your terminal:

$ next dev
   ▲ Next.js 16.1.0 (Turbopack)
   - Local:        http://localhost:3000
   - Environments: .env.local

 ✓ Starting...
 ✓ Ready in 412ms
Enter fullscreen mode Exit fullscreen mode

With File System Caching in 16.1, subsequent starts are even faster—the Ready in 412ms can drop to under 200ms for cached projects.

Configuration Deep Dive

Turbopack has its own configuration section in next.config.js. Here's what you can customize:

Basic Configuration 

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    turbo: {
      // Turbopack-specific options
    }
  }
};

module.exports = nextConfig;
Enter fullscreen mode Exit fullscreen mode

Custom Loaders

One of the biggest Webpack features is custom loaders. Turbopack supports them through a different syntax:

// next.config.js
const nextConfig = {
  experimental: {
    turbo: {
      rules: {
        // SVG as React components
        '*.svg': {
          loaders: ['@svgr/webpack'],
          as: '*.js',
        },
        // GraphQL files
        '*.graphql': {
          loaders: ['graphql-tag/loader'],
          as: '*.js',
        },
        // YAML support
        '*.yaml': {
          loaders: ['yaml-loader'],
          as: '*.json',
        },
      },
    },
  },
};
Enter fullscreen mode Exit fullscreen mode

Note: Not all Webpack loaders work with Turbopack. The Turbopack team maintains a compatibility list.

Resolve Aliases

If you use path aliases, configure them in both tsconfig.json and Turbopack:

// next.config.js
const nextConfig = {
  experimental: {
    turbo: {
      resolveAlias: {
        // Map @components to src/components
        '@components': './src/components',
        '@utils': './src/utils',
        '@hooks': './src/hooks',
        // Compatibility shim for older packages
        'underscore': 'lodash',
      },
    },
  },
};
Enter fullscreen mode Exit fullscreen mode

Resolve Extensions

Control which file extensions Turbopack considers:

// next.config.js
const nextConfig = {
  experimental: {
    turbo: {
      resolveExtensions: [
        '.tsx',
        '.ts',
        '.jsx',
        '.js',
        '.mjs',
        '.cjs',
        '.json',
      ],
    },
  },
};
Enter fullscreen mode Exit fullscreen mode

Module ID Strategy

Control how modules are identified (affects caching):

// next.config.js
const nextConfig = {
  experimental: {
    turbo: {
      moduleIdStrategy: 'deterministic', // or 'named' for debugging
    },
  },
};
Enter fullscreen mode Exit fullscreen mode

Migrating from Webpack

If your project has custom Webpack configuration, migration requires some work.

Common Migration Scenarios

Custom Webpack Plugins

Before (Webpack):

// next.config.js
const nextConfig = {
  webpack: (config, { isServer }) => {
    config.plugins.push(new MyCustomPlugin());
    return config;
  },
};
Enter fullscreen mode Exit fullscreen mode

After (Turbopack):
Most Webpack plugins don't have Turbopack equivalents yet. Options:

  1. Check if the functionality is built into Turbopack
  2. Use a compatible loader instead
  3. Keep using Webpack for that specific feature

CSS Processing

Turbopack has built-in support for:

  • CSS Modules ✅
  • Sass/SCSS ✅
  • PostCSS ✅
  • Tailwind CSS ✅

Built-in configuration:

// postcss.config.js (still works with Turbopack)
module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
};
Enter fullscreen mode Exit fullscreen mode

Environment-Specific Bundling

Before (Webpack):

const nextConfig = {
  webpack: (config, { dev, isServer }) => {
    if (!dev && !isServer) {
      // Production client-side only
    }
    return config;
  },
};
Enter fullscreen mode Exit fullscreen mode

After (Turbopack):
Turbopack automatically handles environment-specific optimizations. For development, it focuses on speed. For production (when available), it'll focus on size.

What Doesn't Work Yet

As of January 2026 (Next.js 16.1), most features are now stable:

Feature Status
Development builds ✅ Stable (default in 16+)
Production builds ✅ Stable
File System Caching ✅ Stable (16.1+)
Standalone output ✅ Supported
Edge Runtime ✅ Supported
Custom Webpack plugins ❌ Not supported
webpack() config function ❌ Not supported
Some third-party loaders ⚠️ Partial support

Production Builds with Turbopack

Since Next.js 16, Turbopack handles production builds by default.

Production Build Commands 

# Default in Next.js 16+ (uses Turbopack)
next build

# Explicit flag (for older versions or clarity)
next build --turbopack
Enter fullscreen mode Exit fullscreen mode

Production Benchmark

On the same e-commerce project:

Bundler Build Time Bundle Size vs Turbopack
Webpack 5 142s 2.1MB baseline
Turbopack 38s 2.0MB 3.7x faster

Turbopack production builds are significantly faster while producing slightly smaller bundles thanks to improved tree-shaking.

Vercel Deployment

Vercel automatically detects Turbopack:

# Deployment log
Detected Next.js 16.1.0
Using Turbopack for build
Build completed in 38s
Enter fullscreen mode Exit fullscreen mode

No configuration needed—it just works.

Turbopack vs Other Bundlers

How does Turbopack compare to the competition?

Turbopack vs Vite

Aspect Turbopack Vite
Architecture Incremental Rust Native ESM + esbuild
Dev Server ~800ms cold start ~300ms cold start
HMR ~20ms ~50ms
Production Uses Turbopack Uses Rollup
Framework Next.js focused Framework agnostic
Maturity Stable (2025) Stable (2020)

Verdict: Vite has faster cold starts, but Turbopack has faster HMR. Vite is more flexible; Turbopack is more optimized for Next.js.

Turbopack vs esbuild

Aspect Turbopack esbuild
Language Rust Go
HMR Built-in Requires plugin
Incremental Full support Limited
Next.js Native support Requires configuration
Customization Limited Extensive

Verdict: esbuild is faster for simple builds but lacks the incremental architecture that makes Turbopack shine for large projects.

Turbopack vs Rspack

Aspect Turbopack Rspack
Language Rust Rust
Webpack compat Limited High
HMR Excellent Good
Ecosystem Growing Webpack-compatible
Focus Next.js General purpose

Verdict: Rspack is the better choice if you need Webpack plugin compatibility. Turbopack is better if you're all-in on Next.js.

Troubleshooting Common Issues

"Module not found" Errors

If you see module resolution errors after switching to Turbopack:

Error: Cannot find module '@/components/Button'
Enter fullscreen mode Exit fullscreen mode

Fix: Ensure your aliases are configured in Turbopack:

// next.config.js
const nextConfig = {
  experimental: {
    turbo: {
      resolveAlias: {
        '@': './src',
      },
    },
  },
};
Enter fullscreen mode Exit fullscreen mode

Loader Compatibility Issues

If a Webpack loader doesn't work:

Error: Turbopack does not support the 'raw-loader' loader
Enter fullscreen mode Exit fullscreen mode

Options:

  1. Use the built-in ?raw import query: 
   import content from './file.txt?raw';
Enter fullscreen mode Exit fullscreen mode
  1. Find a Turbopack-compatible alternative
  2. Temporarily fall back to Webpack for dev

Memory Issues

If Turbopack uses too much memory:

// next.config.js
const nextConfig = {
  experimental: {
    turbo: {
      memoryLimit: 4096, // MB, default is auto-detected
    },
  },
};
Enter fullscreen mode Exit fullscreen mode

HMR Not Working

If HMR stops working:

  1. Check for circular dependencies
  2. Ensure you're not mutating module-level state
  3. Check if you're using next/dynamic correctly: 
// ✅ Works with HMR
const DynamicComponent = dynamic(() => import('./Component'));

// ❌ Breaks HMR
const DynamicComponent = dynamic(() => import('./Component'), { ssr: false });
Enter fullscreen mode Exit fullscreen mode

When to Stick with Webpack

Despite Turbopack's advantages, Webpack might still be the right choice if:

  1. You rely on specific Webpack plugins that don't have Turbopack alternatives
  2. You need maximum bundle size optimization and want every Webpack optimization plugin
  3. You're not using Next.js and don't want to wait for standalone Turbopack
  4. Your custom Webpack config is extensive and migration cost is high

Hybrid Approach

You can use Turbopack for development and Webpack for production:

{
  "scripts": {
    "dev": "next dev",
    "build": "next build"  // Both use Turbopack in 16+
  }
}
Enter fullscreen mode Exit fullscreen mode

Or if you need Webpack for production specifically:

This gives you fast development while keeping your tested production pipeline.

The Future of Turbopack

What's Already Shipped (as of January 2026)

  • ✅ Next.js 16 (October 2025): Turbopack as default bundler
  • ✅ Next.js 16.1 (December 2025): File System Caching stable
  • ✅ Production builds: Fully stable
  • ✅ 5-10x faster Fast Refresh, 2-5x faster builds

2026 Roadmap

Based on Vercel's announcements:

  • Q1 2026: Standalone Turbopack (not Next.js-specific)
  • Q2 2026: Plugin API for custom transformations
  • Q3 2026: Full Webpack config migration tool
  • Ongoing: Build Adapters API, improved monorepo support
  • Build Caching: Persistent caching across builds
  • Distributed Builds: Remote caching and distributed compilation

Conclusion

Turbopack represents a fundamental shift in how we think about JavaScript bundling. It's not just "faster Webpack"—it's a new architecture designed for the scale of modern web applications.

Should you use it?

  • For development: Yes, absolutely. The speed improvement is transformative.
  • For production: Yes, if you're on Next.js 16.1+. It's stable and faster.
  • If migration is complex: Use the hybrid approach—Turbopack for dev, Webpack for prod.

The JavaScript ecosystem is moving toward Rust-powered tooling. SWC replaced Babel. Biome is challenging ESLint. And now Turbopack is taking on Webpack. Whether you switch today or next year, this is where the ecosystem is heading.

Start with next dev and experience the difference yourself. Once you've felt sub-second HMR, you won't want to go back. 🚀

💡 Note: This article was originally published on the Pockit Blog.

Check out Pockit.tools for 60+ free developer utilities. For faster access, add it to Chrome and use JSON Formatter & Diff Checker directly from your toolbar.

Top comments (0)