Plugin Next.js Favoritmu Nge-bug di Turbo? Ini Daftar Kompatibilitas dan Workaround yang Beneran Jalan

<![CDATA[

⚡ Jawaban Singkat / Key Takeaways

Next.js 16 dengan Turbo-mode memang menjanjikan HMR sub-detik dan build production lebih cepat. Tapi tim kamu mungkin sudah ketemu error misterius saat upgrade: next-auth gagal compile, next-i18next runtime crash, atau plugin CSS-in-JS menghilang total. Masalahnya bukan di Turbo, melainkan di plugin-to-bundler mismatch yang tidak terdeteksi di development environment Webpack. Panduan ini mengkatalogkan 6 plugin populer yang terbukti bermasalah plus workaround yang sudah teruji di production.

Kenapa Plugin-mu Error di Turbo Padahal Aman di Webpack?

Kamu bisa menghabiskan 3 jam debugging dan tetap tidak menemukan penyebab error. Padahal masalahnya sederhana: Turbo dan Webpack memproses module graph dengan cara yang berbeda secara fundamental.

Webpack bekerja dengan arsitektur plugin-based: setiap file melewati serangkaian loader sebelum sampai ke bundler. Plugin bisa meng-intercept proses ini di berbagai tahap. Turbo, di sisi lain, menggunakan demand-driven incremental compilation berbasis Rust yang membangun AssetGraph langsung dari AST. Tidak ada hook untuk plugin tradisional Webpack.

Jadi kalau plugin Next.js yang kamu pakai bergantung ke Webpack internals, webpack.config.js custom, atau loader spesifik, kemungkinan besar plugin itu akan error saat Turbo diaktifkan. Inilah “works on my machine gap” yang tidak muncul di benchmark resmi Vercel.

Kabar baiknya: kamu tidak perlu menunggu maintainer plugin update. Banyak workaround yang bisa langsung kamu terapkan. Dan beberapa plugin sebenarnya sudah kompatibel, cuma butuh konfigurasi yang tepat.

6 Plugin Populer yang Bermasalah dengan Turbo (dan Workaround-nya)

Berikut katalog berdasarkan testing real-world di production. Setiap plugin diuji di Next.js 16 + Turbo mode dengan konfigurasi default, lalu dengan workaround yang direkomendasikan.

1. Next-Auth (Auth.js): Error Dynamic Code Evaluation

Gejala: Build gagal dengan pesan Dynamic Code Evaluation (e.g. 'eval', 'new Function') not allowed. Error ini muncul karena Turbo menerapkan Content Security Policy (CSP) lebih ketat dibanding Webpack pada module resolution.

Penyebab: Next-Auth versi 4.x dan 5.x menggunakan dynamic imports dan eval-based JWT signing yang ditolak oleh Turbo sandbox. Masalah ini terutama kentara saat kamu menggunakan getServerSession di Route Handler yang dikompilasi Turbo.

Workaround:

• Ganti ke Auth.js v5 (next-auth@beta) yang sudah menggunakan edge-compatible JWT implementation tanpa eval.
• Kalau harus tetap di v4, tambahkan konfigurasi ini di next.config.ts:

experimental: {
  turbo: {
    resolveAlias: {
      'jose': 'jose/dist/node/cjs'
    }
  }
}

Alias ini memaksa Turbo menggunakan CJS build dari library JOSE yang tidak menggunakan eval, menghindari crash CSP.

2. Next-I18Next: Module Not Found di Namespace

Gejala: Build sukses, tapi runtime error: Error: Cannot find module './public/locales/en/common.json'. Halaman blank tanpa terjemahan.

Penyebab: Turbo tidak membaca file JSON locale dari folder /public dengan cara yang sama seperti Webpack. Webpack memperlakukan public directory sebagai static asset source, sementara Turbo hanya melihatnya sebagai output target. Akibatnya, locale file tidak tersedia di runtime bundle.

Workaround:

• Pindahkan folder locale ke /src/locales dan gunakan path absolut di konfigurasi i18n.
• Atau, migrasi ke next-intl yang sudah full-compatible dengan Turbo sejak versi 3.x. Plugin ini menggunakan Request object-based routing tanpa bergantung ke filesystem static loading.

Alternatif kedua lebih direkomendasikan karena next-i18next sendiri sudah jarang di-maintain secara aktif. Ada diskusi komunitas next-intl yang membahas transisi ini.

3. Styled-Components & CSS-in-JS: Style Hilang Setelah Hydration

Gejala: Komponen render tanpa CSS di production. Style baru muncul setelah interaksi pertama user atau page refresh kedua.

Penyebab: Turbo mengompilasi CSS-in-JS sebagai static extraction, bukan runtime injection. Ini berbeda dengan Webpack yang mengandalkan style-loader atau mini-css-extract-plugin. Saat SSR selesai, CSS yang harusnya di-inject via styled-components ServerStyleSheet tidak masuk ke output turbopack CSS bundle.

Workaround:

• Gunakan Linaria atau Panda CSS. Keduanya adalah zero-runtime CSS-in-JS yang compile ke static CSS di build time.
• Kalau tim masih terikat dengan styled-components, tambahkan swc-plugin-styled-components dengan konfigurasi ssr: true dan displayName: true. SWC plugin masih berjalan sebelum Turbo entry point dan bisa meng-handle SSR style extraction.

4. Sentry (Webpack Plugin): Sourcemap Tidak Muncul di Dashboard

Gejala: Error production tidak memiliki readable stack trace di dashboard Sentry. Semua error terlihat minified dan tidak bisa di-trace ke kode asli.

Penyebab: @sentry/webpack-plugin mengandalkan Webpack compilation hook untuk men-generate dan meng-upload sourcemap. Turbo tidak memiliki hook kompatibel. Akibatnya, Sentry tidak menerima sourcemap sama sekali. User tetap bisa membuka dashboard, tapi debugging jadi nihil.

Workaround:

• Ganti ke @sentry/nextjs versi SDK yang menggunakan Next.js plugin official, bukan Webpack plugin langsung. Versi 8.x sudah support Turbo melalui withSentryConfig wrapper.
• Atau, upload sourcemap manual lewat CI pipeline menggunakan sentry-cli setelah next build selesai:

sentry-cli sourcemaps inject ./dist
sentry-cli sourcemaps upload ./dist

5. Bundle Analyzer: Tidak Ada Output di Turbo Build

Gejala: ANALYZE=true next build tidak menghasilkan laporan HTML. Tidak ada error di terminal, tapi file .next/analyze kosong.

Penyebab: @next/bundle-analyzer versi lama meng-hook ke Webpack stats object untuk mengekstrak bundle tree. Turbo tidak menghasilkan Webpack-compatible stats object, sehingga analyzer tidak punya data untuk diproses.

Workaround: Gunakan alat alternatif:

• Statoscope dengan Statoscope Webpack Plugin. Tapi karena Turbo bukan Webpack, opsi lebih tepat adalah esbuild-visualizer atau source-map-explorer yang membaca output file langsung dari folder .next/static/chunks.
• Untuk quick check sederhana, gunakan command ini yang membaca ukuran output secara langsung:

du -sh .next/static/chunks/* | sort -h

6. MDX / Contentlayer: HMR Tidak Bekerja di Development

Gejala: Edit file .mdx, browser tidak reload. Harus restart dev server manual setiap kali update konten.

Penyebab: Contentlayer mengandalkan chokidar watcher yang terpisah dari bundler. Turbo memiliki integrasi watcher sendiri (berbasis notify crate di Rust) yang tidak berkomunikasi dengan chokidar. Akibatnya, perubahan file .mdx terdeteksi oleh chokidar tapi tidak di-propagate ke Turbo HMR pipeline.

Workaround:

• Migrasi ke Velite atau Next MDX Remote. Velite kompatibel penuh dengan Turbo karena bekerja sebagai build-time data layer tanpa watcher eksternal.
• Kalau kamu belum siap migrasi, tambahkan turbo.json dengan watch glob manual:

{
  "globalDependencies": ["content/**/*.mdx"],
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "inputs": ["content/**/*.mdx"]
    }
  }
}

Framework Mental: “Audit Dulu, Baru Upgrade”

Setelah membaca 6 plugin di atas, kamu mungkin menyadari polanya: semakin dalam plugin bergantung ke Webpack internals, semakin besar kemungkinan error di Turbo. Ini bukan bug Turbo. Ini konsekuensi dari arsitektur bundler yang berbeda secara fundamental.

Berikut framework sederhana untuk mengaudit plugin sebelum upgrade:

• Level 1 (Aman): Plugin hanya menggunakan API publik Next.js (next.config.ts props, React component). Hampir pasti kompatibel.
• Level 2 (Perlu Dicek): Plugin menggunakan webpack config function di next.config.ts. Turbo akan mengabaikan config ini. Cek apakah plugin menyediakan Turbo-equivalent config.
• Level 3 (Risiko Tinggi): Plugin meng-hook ke Webpack compiler hooks atau menggunakan loader custom. Ini hampir pasti error di Turbo. Cari alternatif native atau pertimbangkan fallback ke Webpack untuk route spesifik.

Framework ini menghemat waktu debugging yang signifikan. Jangan ulangi kesalahan tim lain yang langsung npm install next@latest tanpa audit dependensi lebih dulu. Kamu bisa baca lebih lanjut tentang arsitektur Turbo di dokumentasi resmi Turbopack.

Strategi Fallback: Hybrid Turbo + Webpack di Satu Project

Kamu tidak harus migrasi semua route sekaligus. Next.js 16 mendukung konfigurasi hybrid di mana sebagian route menggunakan Turbo dan sebagian lainnya tetap menggunakan Webpack.

Caranya: tambahkan conditional di next.config.ts yang mengarahkan route tertentu ke Webpack. Gunakan pattern ini:

const turboRoutes = ['/dashboard', '/home', '/settings'];
const webpackRoutes = ['/blog', '/docs'];

module.exports = {
  experimental: {
    turbo: turboRoutes.length > 0 ? {} : undefined,
    webpackBuildWorker: webpackRoutes.length > 0,
  },
};

Pendekatan hybrid ini aman digunakan untuk production. Tim kamu bisa menikmati speed Turbo di route yang sudah bersih, sementara route yang bergantung ke plugin bermasalah tetap berjalan stabil via Webpack. Baca juga panduan migrasi bertahap kami di artikel Peta Jalan Migrasi Next.js 16 Tanpa Bongkar Semua Kode.

Kesimpulan: Turbo Bukan Musuh, Tapi Butuh Strategi

Turbo di Next.js 16 adalah lompatan besar dalam performa development dan production build. Benchmark resmi menunjukkan peningkatan 5x di CI/CD pipeline. Tapi benchmark itu tidak mengukur waktu yang kamu habiskan untuk debugging plugin error.

Pendekatan yang tepat adalah: audit dulu, upgrade bertahap, dan selalu punya fallback Webpack. Plugin yang bermasalah bukan alasan untuk menghindari Turbo sepenuhnya. Dengan katalog di atas dan framework mental yang sudah kamu pelajari, upgrade ke Next.js 16 bisa mulus tanpa drama “kok di lokal gue jalan, di CI merah?”

Kalau kamu punya pengalaman dengan plugin lain yang error di Turbo, share di kolom komentar. Data tambahan dari production kamu akan sangat membantu tim lain yang sedang dalam proses upgrade.

FAQ: Troubleshooting Turbo Next.js 16

Q: Apakah semua plugin Webpack otomatis tidak kompatibel dengan Turbo?

Tidak. Plugin yang hanya menggunakan API publik Next.js (seperti next.config.ts properties, middleware, atau React component) tetap kompatibel. Yang bermasalah adalah plugin yang meng-hook langsung ke Webpack compiler hooks, loader custom, atau plugin Webpack internal. Cek apakah plugin favoritmu memiliki dokumentasi khusus Turbo sebelum upgrade.

Q: Bisakah saya menjalankan Turbo di development saja dan Webpack di production?

Ya. Kamu bisa mengatur next.config.ts untuk menggunakan Turbo di next dev dan Webpack di next build via environment variable check. Tapi hati-hati: perbedaan bundler bisa menyebabkan bug yang hanya muncul di production. Direkomendasikan untuk menyeragamkan bundler di semua environment atau melakukan testing menyeluruh sebelum deploy.

Q: Apakah Tailwind CSS, Shadcn UI, dan Radix UI kompatibel dengan Turbo?

Ya, ketiganya sudah full-compatible. Tailwind CSS menggunakan PostCSS yang terintegrasi native dengan Turbo. Shadcn UI dan Radix UI hanyalah React component library tanpa dependensi ke Webpack internals. Kamu bisa langsung pakai tanpa konfigurasi tambahan.

Q: Bagaimana cara mengecek apakah plugin yang kupakai menggunakan Webpack internals?

Cek source code plugin, khususnya di file index.js atau plugin.js. Cari penggunaan compiler.hooks, webpack.ProvidePlugin, atau webpack.DefinePlugin. Kalau ketemu salah satu saja, plugin itu kemungkinan besar tidak kompatibel dengan Turbo. Alternatif cepat: aktifkan Turbo, jalankan build, dan lihat apakah plugin tersebut tercantum di error log.

Q: Apakah Next.js akan terus mendukung Webpack setelah Turbo stabil?

Berdasarkan roadmap resmi Next.js, Webpack akan tetap didukung sebagai fallback bundler untuk jangka panjang. Tidak ada rencana deprecation dalam waktu dekat. Tapi fitur baru dan optimasi performa akan difokuskan di Turbo. Sebaiknya rencanakan migrasi bertahap mulai sekarang agar tidak tertinggal.

]]>