Turbopack em 2026: Guia Completo do Bundler do Next.js Feito em Rust

Se você atualizou pro Next.js 16 recentemente, provavelmente notou algo diferente. Seu servidor de dev inicia em menos de um segundo. As atualizações de HMR acontecem antes de você piscar. E aqui tá a grande mudança: Turbopack agora é o bundler padrão—sem flags necessários.

Bem-vindo à nova era do bundling JavaScript.

Turbopack tá cozinhando desde 2022 quando a Vercel anunciou como "o sucessor do Webpack." Depois de anos de desenvolvimento, chegou a stable pra dev no Next.js 15, e com o Next.js 16 (outubro 2025), virou o bundler padrão pra todas as aplicações. O último Next.js 16.1 (dezembro 2025) adicionou File System Caching stable, deixando ainda mais rápido.

Vamos descobrir.

O que é Turbopack?

Turbopack é um bundler JavaScript/TypeScript baseado em Rust feito pela Vercel, desenvolvido especificamente pro Next.js mas com planos de se tornar framework-agnostic. Não é um drop-in replacement do Webpack—é uma reescrita do zero que repensa como bundling deveria funcionar em 2026.

O Problema com o Webpack

Webpack revolucionou o bundling JavaScript quando lançou em 2012. Mas foi projetado pra uma era diferente:

• Projetos tinham centenas de arquivos, não dezenas de milhares
• Node.js era a única opção de runtime
• TypeScript e JSX não eram mainstream
• HMR era um nice-to-have, não um requisito

Avançando pra 2026, a arquitetura do Webpack tá mostrando a idade:

# Projeto típico Next.js 14 com Webpack
Cold start: 12-45 segundos
Atualização HMR: 1-5 segundos
Rebuild completo: 30-120 segundos

O problema não é culpa do Webpack—é que JavaScript é fundamentalmente lento pra tarefas intensivas como bundling. Nenhuma quantidade de otimização consegue superar o teto de performance do V8.

A Vantagem do Rust

Turbopack é escrito em Rust, o que dá várias vantagens:

1. Performance Nativa: Rust compila pra código de máquina, eliminando o overhead do V8
2. Paralelismo Real: O modelo de ownership do Rust permite multithreading seguro sem pausas de GC
3. Eficiência de Memória: Gerenciamento manual de memória significa sem spikes de garbage collection
4. Projetado pra Incrementalidade: O sistema de tipos do Rust facilita construir computação incremental correta

Mas só Rust não é o molho secreto. Turbopack introduz uma arquitetura fundamentalmente diferente.

O Motor Turbo

No núcleo do Turbopack tá o "Motor Turbo," um sistema de memoização e computação incremental. Pensa nele como um cache inteligente que:

1. Lembra de tudo: Todo resultado de chamada de função é cacheado
2. Rastreia dependências: Sabe quais outputs dependem de quais inputs
3. Invalida minimamente: Quando um arquivo muda, só as computações afetadas são re-executadas

Bundler tradicional:
  Arquivo muda → Rebuild do bundle inteiro → Envia pro browser

Turbopack:
  Arquivo muda → Recomputa só os módulos afetados → Envia delta pro browser

Por isso HMR com Turbopack parece instantâneo—tá literalmente fazendo menos trabalho.

Benchmarks de Performance

Vamos aos números. Esses benchmarks foram rodados numa aplicação real de e-commerce Next.js 15.

Ambiente de Teste

• Projeto: 2.847 arquivos TypeScript, 156 componentes React
• Hardware: M3 MacBook Pro, 36GB RAM
• Node.js: v22.1.0
• Next.js: 16.1.0

Cold Start (Servidor Dev)

Hot Module Replacement

Compilação de Página (Nova Rota)

Uso de Memória (Servidor Dev Rodando)

Os números não mentem. Turbopack é dramaticamente mais rápido pra fluxos de desenvolvimento.

Começando com Turbopack

Habilitando Turbopack

No Next.js 16+, Turbopack tá habilitado por padrão—sem configuração necessária. Só roda:

# Turbopack agora é o padrão!
next dev

# Se você tá no Next.js 15.x antigo:
next dev --turbopack

Verificando se Tá Funcionando

Você vai ver confirmação no terminal:

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

 ✓ Starting...
 ✓ Ready in 847ms

O indicador (Turbopack) confirma que você tá usando o novo bundler.

Configuração Detalhada

Turbopack tem sua própria seção de configuração no next.config.js. Aqui tá o que você pode customizar:

Configuração Básica

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    turbo: {
      // Opções específicas do Turbopack
    }
  }
};

module.exports = nextConfig;

Loaders Customizados

Uma das maiores features do Webpack são loaders customizados. Turbopack suporta eles com sintaxe diferente:

// next.config.js
const nextConfig = {
  experimental: {
    turbo: {
      rules: {
        // SVG como componentes React
        '*.svg': {
          loaders: ['@svgr/webpack'],
          as: '*.js',
        },
        // Arquivos GraphQL
        '*.graphql': {
          loaders: ['graphql-tag/loader'],
          as: '*.js',
        },
        // Suporte YAML
        '*.yaml': {
          loaders: ['yaml-loader'],
          as: '*.json',
        },
      },
    },
  },
};

Nota: Nem todos os loaders do Webpack funcionam com Turbopack. O time do Turbopack mantém uma lista de compatibilidade.

Aliases de Resolução

Se você usa path aliases, configure em tsconfig.json e no Turbopack:

// next.config.js
const nextConfig = {
  experimental: {
    turbo: {
      resolveAlias: {
        // Mapeia @components pra src/components
        '@components': './src/components',
        '@utils': './src/utils',
        '@hooks': './src/hooks',
        // Shim de compatibilidade pra pacotes antigos
        'underscore': 'lodash',
      },
    },
  },
};

Migrando do Webpack

Se seu projeto tem configuração customizada de Webpack, a migração requer um trabalho.

Cenários Comuns de Migração

Plugins Customizados de Webpack

Antes (Webpack):

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

Depois (Turbopack):
A maioria dos plugins de Webpack ainda não tem equivalentes no Turbopack. Opções:

1. Verificar se a funcionalidade já tá incorporada no Turbopack
2. Usar um loader compatível no lugar
3. Manter Webpack pra essa feature específica

Processamento CSS

Turbopack tem suporte built-in pra:

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

O que Ainda Não Funciona

Em janeiro de 2026, algumas features ainda são só Webpack:

Builds de Produção com Turbopack

A grande notícia de 2026: builds de produção com Turbopack estão stable.

Habilitando Turbopack pra Produção

# Padrão no Next.js 16+ (usa Turbopack)
next build

# Flag explícito (pra versões antigas)
next build --turbopack

Benchmark de Produção

No mesmo projeto de e-commerce:

Builds de produção com Turbopack são significativamente mais rápidos enquanto produzem bundles ligeiramente menores graças a tree-shaking melhorado.

Turbopack vs Outros Bundlers

Como o Turbopack se compara com a competição?

Turbopack vs Vite

Veredito: Vite tem cold starts mais rápidos, mas Turbopack tem HMR mais rápido. Vite é mais flexível; Turbopack é mais otimizado pro Next.js.

Turbopack vs Rspack

Veredito: Rspack é melhor escolha se você precisa de compatibilidade com plugins de Webpack. Turbopack é melhor se você tá all-in com Next.js.

Resolvendo Problemas Comuns

Erros "Module not found"

Se você vê erros de resolução de módulo depois de trocar pro Turbopack:

Error: Cannot find module '@/components/Button'

Solução: Garanta que seus aliases estão configurados no Turbopack:

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

Problemas de Compatibilidade de Loader

Se um loader de Webpack não funciona:

Error: Turbopack does not support the 'raw-loader' loader

Opções:

1. Usar a query de import ?raw built-in:

   import content from './file.txt?raw';

2. Achar uma alternativa compatível com Turbopack
3. Temporariamente voltar pro Webpack pra dev

Quando Manter o Webpack

Apesar das vantagens do Turbopack, Webpack pode ainda ser a escolha certa se:

1. Você depende de plugins específicos de Webpack que não têm alternativas no Turbopack
2. Precisa de otimização máxima de tamanho de bundle e quer usar todos os plugins de otimização do Webpack
3. Não usa Next.js e não quer esperar o Turbopack standalone
4. Sua config de Webpack é extensa e o custo de migração é alto

Abordagem Híbrida

Você pode usar Turbopack pra desenvolvimento e Webpack pra produção:

{
  "scripts": {
    "dev": "next dev",
    "build": "next build"  // Ambos usam Turbopack no 16+
  }
}

Se você precisa de Webpack pra produção, fica no 15.x ou ajusta a config.

O Futuro do Turbopack

Roadmap 2026

Baseado nos anúncios da Vercel:

• Q1 2026: Turbopack padrão no Next.js 16
• Q2 2026: Turbopack standalone (não específico de Next.js)
• Q3 2026: API de plugins pra transformações customizadas
• Q4 2026: Ferramenta completa de migração de config do Webpack

O que Vem Aí

1. Sistema de Plugins: Escrever plugins customizados de Turbopack em Rust ou JavaScript
2. Suporte a Frameworks: Adaptadores oficiais pra Remix, Nuxt, SvelteKit
3. Build Caching: Cache persistente entre builds
4. Builds Distribuídos: Cache remoto e compilação distribuída

Conclusão

Turbopack representa uma mudança fundamental em como pensamos sobre bundling JavaScript. Não é só "Webpack mais rápido"—é uma nova arquitetura projetada pra escala de aplicações web modernas.

Deveria usar?

• Pra desenvolvimento: Sim, com certeza. A melhoria de velocidade é transformadora.
• Pra produção: Sim, se você tá no Next.js 16.1+. Tá stable e rápido.
• Se a migração é complexa: Use a abordagem híbrida—Turbopack pra dev, Webpack pra prod.

O ecossistema JavaScript tá se movendo pra ferramentas feitas em Rust. SWC substituiu o Babel. Biome tá desafiando o ESLint. E agora Turbopack tá enfrentando o Webpack. Seja que você troque hoje ou ano que vem, é pra onde o ecossistema tá indo.

Comece com next dev e experimente a diferença você mesmo. Uma vez que você sentir HMR de 0.5 segundo, não vai querer voltar. 🚀