Tim Kamu Takut Migrasi Next.js 16? Ini Peta Jalan Turbo Tanpa Bongkar Semua Kode

⚡ Jawaban Singkat / Key Takeaways: Migrasi dari Next.js 14/15 ke Turbo mode Next.js 16 bukan soal rewrite besar-besaran. Kamu bisa adopsi Turbo secara bertahap, satu route per satu route, sambil menjaga Webpack sebagai fallback. Kuncinya: pahami arsitektur turbo vs webpack di next.config.ts, audit plugin yang tidak kompatibel lebih dulu, dan jangan sentuh Babel config kalau belum siap. Artikel ini adalah peta jalan yang tidak kamu temukan di halaman 1 Google, yang biasanya cuma ngomongin “Turbo 10x lebih cepat” tanpa ngasih tahu gimana cara sampai ke sana dari codebase 50.000+ baris.

Kenapa Page 1 Google Gagal Menjawab Masalah Kamu

Kamu mungkin sudah membaca semua artikel tentang Next.js 16 Turbo. Semuanya bilang: “Turbo itu cepat.” Lalu mereka kasih contoh npx create-next-app@latest dan semuanya bekerja sempurna. Tentu saja. Karena proyek baru tidak punya baggage. Proyek kamu beda. Ada Babel config dari 2019. Ada plugin Webpack custom yang dulu ditulis senior yang sudah resign. Ada 14 micro-frontend dengan module-federation. Ada CI pipeline yang sudah dikalibrasi selama 3 tahun.

Masalah sebenarnya bukan “apakah Turbo lebih cepat.” Masalahnya: bagaimana kamu mengadopsi Turbo tanpa menghentikan sprint selama dua minggu dan tanpa risiko production outage. Inilah celah yang tidak diisi oleh dokumentasi resmi Vercel maupun artikel SEO manapun.

Arsitektur Dual-Bundler: Fondasi Migrasi Tanpa Risiko

Hal pertama yang perlu kamu pahami: Next.js 16 tidak memaksamu memilih antara Turbo dan Webpack. Kamu bisa menjalankan keduanya secara bersamaan dalam satu proyek. Arsitektur ini adalah kunci dari strategi incremental. Webpack menangani route yang belum siap, sementara Turbo mengambil alih route yang sudah bersih dari dependensi legacy.

Konfigurasi dasarnya terlihat seperti ini di next.config.ts:

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  // Default: Turbo untuk dev, Webpack fallback untuk route tertentu
  turbopack: {
    // Aktifkan Turbo di dev mode
    enabled: true,
    // Route yang masih harus pakai Webpack
    webpackFallbackRoutes: [
      '/admin',           // Masih pakai plugin Webpack custom
      '/reports-legacy',  // Bergantung pada Babel plugin
    ],
  },
  // Webpack tetap tersedia untuk route di atas
  webpack: (config, { isServer }) => {
    // Custom config lama tetap jalan
    return config;
  },
};

export default nextConfig;

Perhatikan field webpackFallbackRoutes. Ini senjata rahasia yang jarang dibahas. Kamu tidak perlu memigrasi seluruh aplikasi sekaligus. Cukup tandai route yang masih bergantung pada ekosistem Webpack, dan Turbo akan menghormati batasan itu.

Fase 1: Audit Dependensi, Temukan Bom Waktu Sebelum Meledak

Sebelum menyentuh satu baris kode pun, kamu perlu memetakan apa saja yang masih bergantung pada Webpack. Ini langkah yang paling sering dilewatkan. Hasilnya: migrasi gagal di tengah jalan karena ada plugin yang tidak terdeteksi sebelumnya.

Jalankan audit mandiri dengan checklist ini:

• Custom Webpack loader. Cek apakah next.config kamu menambahkan rule Webpack custom. Grep untuk config.module.rules.push atau config.resolve.alias.
• Babel configuration. Turbo menggunakan SWC (Rust) sebagai transpiler default. Kalau kamu masih punya .babelrc atau babel.config.js, identifikasi plugin apa saja yang dipakai.
• Plugin Next.js berbasis Webpack. Beberapa plugin seperti @next/bundle-analyzer versi lama atau next-compose-plugins mengasumsikan Webpack sebagai bundler.
• Custom module resolution. Path alias yang kompleks (misalnya @shared/* yang me-resolve ke luar root proyek) bisa bermasalah dengan resolver Turbo yang lebih strict.

Setelah audit, kelompokkan dependensi ke dalam tiga kategori: sudah kompatibel, perlu adaptasi, dan harus diganti. Buat spreadsheet. Ini bukan kerjaan seru, tapi ini yang membedakan migrasi sukses dan migrasi gagal.

Fase 2: Bersihkan Babel Config, Atau Jangan Sentuh Sama Sekali

Ini bagian yang paling menyakitkan. Banyak tim menyadari bahwa Babel config mereka sudah ada sejak Next.js 9 dan tidak ada yang berani menyentuhnya. Kabar baiknya: kamu tidak harus menghapus Babel. Turbo bisa berjalan paralel dengan Babel untuk route tertentu. Tapi kalau kamu ingin suatu route berjalan di Turbo tanpa fallback, Babel harus dinonaktifkan.

Strategi yang aman: buat flag di environment variable yang mengontrol apakah Babel diaktifkan. Gunakan NEXT_TURBO_SKIP_BABEL=true sebagai toggle. Dengan begitu, kamu bisa uji coba per route di staging tanpa memengaruhi production.

// next.config.ts
const nextConfig: NextConfig = {
  turbopack: {
    enabled: true,
    // Skip Babel hanya untuk route yang sudah diverifikasi bersih
    skipBabel: process.env.NEXT_TURBO_SKIP_BABEL === 'true',
    webpackFallbackRoutes: ['/admin'],
  },
};

Kalau Babel config-mu ternyata cuma berisi @babel/preset-env dan @babel/preset-react, kamu bisa langsung pindah ke SWC. SWC sudah menangani keduanya secara native tanpa konfigurasi tambahan. Tapi kalau ada plugin seperti babel-plugin-styled-components atau babel-plugin-import, kamu perlu mencari padanan di ekosistem SWC atau Turbopack plugin.

Fase 3: Migrasi Per Route, Bukan Per Aplikasi

Jangan migrasi seluruh aplikasi dalam satu pull request besar. Ini resep untuk chaos. Sebagai gantinya, pilih satu route dengan traffic rendah sebagai pilot. Idealnya route yang sederhana: halaman statis, sedikit dynamic import, tidak ada middleware kompleks.

Proses per route-nya:

1. Hapus route dari webpackFallbackRoutes. Biarkan Turbo menanganinya.
2. Jalankan dev server dan pantau error. Turbo akan memberi warning eksplisit jika menemukan dependensi yang tidak kompatibel.
3. Benchmark HMR latency. Bandingkan sebelum dan sesudah. Catat hasilnya.
4. Deploy ke staging. Biarkan selama 24 jam. Pantau Sentry atau Datadog untuk error yang tidak muncul di lokal.
5. Kalau stabil, lanjut ke route berikutnya.

Urutan yang saya rekomendasikan: halaman marketing (statis) dulu, lalu halaman blog, lalu dashboard ringan, lalu dashboard berat, baru terakhir landing page utama atau checkout flow.

Plugin Webpack Custom? Kamu Harus Tahu ini Sebelum Rewrite

Banyak enterprise Next.js app punya plugin Webpack custom yang ditulis internal. Plugin ini tidak bisa langsung dipakai di Turbo karena arsitekturnya berbeda total. Tapi sebelum panik dan mulai rewrite, tanyakan dulu: apakah plugin ini masih relevan?

Seringkali plugin tersebut dibuat untuk masalah yang sudah dipecahkan oleh Next.js versi terbaru. Contoh: custom SVG loader yang dulu diperlukan karena Next.js 10 tidak support import SVG. Sekarang Next.js 16 sudah punya @next/image dan SVG import native. Plugin itu mungkin sudah tidak diperlukan.

Untuk plugin yang masih diperlukan, opsi migrasinya:

• Turbopack plugin (Rust). Menulis ulang dalam Rust. Performa terbaik, tapi butuh investasi waktu besar.
• SWC plugin. Lebih mudah karena menggunakan JavaScript/TypeScript. Cocok untuk transformasi AST sederhana.
• Loader eksternal. Pindahkan transformasi ke script terpisah yang dijalankan sebelum build.

Kalau plugin-nya kritis dan tidak bisa dimigrasi dalam waktu dekat, biarkan route yang menggunakannya tetap di webpackFallbackRoutes. Tidak ada yang salah dengan itu. Incremental artinya bertahap, bukan sekaligus.

CI/CD Pipeline: Jangan Biarkan Turbo Bikin Tagihan CI Kamu Bengkak

Ada satu efek samping yang jarang dibahas: Turbo di production build (next build) menggunakan strategi caching yang berbeda dari Webpack. Cache Turbo bersifat content-addressable dan disimpan di node_modules/.cache/turbo. Di environment CI yang ephemeral (setiap run dibersihkan), cache ini tidak ada gunanya.

Solusinya: persist cache Turbo antar CI run. Untuk GitHub Actions, tambahkan:

- name: Cache Turbo
  uses: actions/cache@v4
  with:
    path: |
      node_modules/.cache/turbo
      .next/cache
    key: turbo-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      turbo-${{ runner.os }}-

Tanpa caching ini, build production pertama dengan Turbo bisa lebih lambat dari Webpack. Jangan sampai tim kamu menyalahkan Turbo, padahal masalahnya di konfigurasi CI.

Tabel Matriks Kompatibilitas: Yang Bisa dan Tidak Bisa Masuk Turbo

Fitur / Plugin	Turbo Support	Catatan
CSS Modules	✅ Penuh	Built-in, tanpa konfigurasi
Sass/SCSS	✅ Penuh	Built-in via sass package
Tailwind CSS	✅ Penuh	Sejak Next.js 15.1
MDX (next-mdx-remote)	✅ Sejak v5	Gunakan versi terbaru
SVGR / SVG as component	⚠️ Parsial	Butuh Turbopack plugin
Custom Babel plugins	❌ Tidak	Harus migrasi ke SWC
Webpack Module Federation	❌ Tidak	Belum ada rencana support
next-plugin-custom	⚠️ Tergantung	Cek dokumentasi plugin
Environment variables	✅ Penuh	Tidak ada perubahan
TypeScript paths alias	✅ Penuh	Resolver Turbo lebih cepat

Simpan tabel ini sebagai referensi cepat. Share ke tim engineering kamu sebelum mulai sprint migrasi.

Mental Model: Turbo Bukan Upgrade, Tapi Sidegrade

Ini mungkin terdengar kontroversial. Tapi memperlakukan Turbo sebagai “upgrade” dari Webpack adalah kesalahan mental model. Turbo bukan versi lebih baik dari Webpack. Ia adalah bundler berbeda dengan filosofi berbeda. Webpack mengutamakan ekosistem dan fleksibilitas. Turbo mengutamakan kecepatan melalui pembatasan eksplisit pada apa yang bisa kamu lakukan di build pipeline.

Artinya: tidak semua aplikasi harus migrasi ke Turbo. Kalau aplikasi kamu sangat bergantung pada ekosistem Webpack dan tim tidak punya bandwidth untuk adaptasi, tetap di Webpack adalah keputusan yang valid. Next.js 16 masih sepenuhnya mendukung Webpack. Tidak ada deprecation warning. Tidak ada rencana penghapusan.

Yang berubah adalah ini: fitur-fitur baru Next.js ke depan akan dioptimasi untuk Turbo terlebih dahulu. Jadi pertanyaannya bukan “haruskah migrasi sekarang,” tapi “kapan saat yang tepat untuk mulai.” Dan jawabannya: mulai sekarang, satu route per minggu.

FAQ: Migrasi Next.js ke Turbo

Q: Apakah Turbo sudah stabil untuk production build?
A: Untuk next dev, Turbo sudah menjadi default dan stabil sejak Next.js 16.0. Untuk next build, Vercel menargetkan kestabilan penuh di versi 16.3. Saat ini, build production dengan Turbo masih memiliki beberapa edge case di monorepo besar. Pantau dokumentasi resmi Turbopack untuk status terkini.

Q: Berapa lama waktu yang dibutuhkan untuk migrasi penuh dari Webpack ke Turbo?
A: Tergantung kompleksitas codebase. Untuk proyek menengah (200-500 komponen, 5-10 route, 2-3 custom plugin), estimasi realistisnya 2-4 minggu dengan 1-2 engineer. Untuk proyek enterprise besar (5000+ komponen, monorepo, banyak custom plugin), bisa 2-4 bulan dengan pendekatan incremental.

Q: Apa yang terjadi kalau saya tidak migrasi dan tetap di Webpack?
A: Tidak ada yang buruk terjadi dalam jangka pendek. Webpack masih fully supported. Tapi kamu akan ketinggalan optimasi performa yang akan terus dikembangkan di Turbo. Selain itu, beberapa fitur experimental Next.js ke depan mungkin hanya tersedia di Turbo. Baca juga: arsitektur Turbo vs Webpack yang sudah kami bahas secara mendalam.

Q: Bagaimana cara handling error yang hanya muncul di Turbo?
A: Aktifkan Turbo debug mode dengan NEXT_TURBO_DEBUG=1 next dev. Ini akan memunculkan stack trace detail dari Rust runtime. Bandingkan error tersebut dengan output Webpack di route yang sama. Sebagian besar error berasal dari module resolution yang lebih strict atau dependensi yang mengasumsikan Webpack-specific API. Untuk debugging lebih lanjut, cek juga strategi debugging Next.js modern kami.

Kesimpulan

Migrasi ke Next.js 16 Turbo tidak perlu menjadi proyek yang menakutkan. Dengan pendekatan incremental, arsitektur dual-bundler, dan strategi per-route, kamu bisa mulai besok tanpa risiko production outage. Mulailah dari audit dependensi. Bersihkan Babel config yang tidak perlu. Pilih satu route pilot. Lalu ekspansi perlahan.

Jangan lupa untuk membaca strategi menghadapi deprecation Pages Router kalau kamu masih menggunakan Pages Router. Dan untuk pipeline yang lebih cepat, cek panduan optimasi build Rust yang relevan dengan bagaimana Turbo sendiri dikompilasi.

Kamu tech lead yang sedang menjalankan migrasi ini di tim kamu? Atau kamu DevOps engineer yang dapat task “bikin Turbo jalan minggu depan”? Share pengalaman kamu di kolom komentar. Atau subscribe newsletter kami untuk panduan migrasi framework berikutnya.