Turbopack je od Next.js 16 stabilný bundler pre produkčné buildy a v next build --turbopack už nie je označený ako experimentálny. Ako architektka, ktorá už dva roky ťahá build system nášho monorepa cez tri väčšie migrácie React verzií, môžem povedať priamo: prechod z Webpacku na Turbopack pre produkčné buildy je najväčší jednorazový výkonový skok, aký som v Next.js infraštruktúre videla. V tomto sprievodcovi vás prevediem zapnutím, migráciou konfigurácie, reálnymi benchmarkami z nášho CI, limitáciami, ktoré musíte poznať pred nasadením, a špecifikami monorepa.
Turbopack je od Next.js 16 stabilný pre produkčné buildy. Zapína sa flagom next build --turbopack alebo v next.config.ts.
Naše CI buildy sa v monorepe s ~1 400 modulmi zrýchlili z 4 min 12 s na 1 min 09 s (2,5 až 3,5× rýchlejšie podľa kombinácie CSS/TSX).
Custom webpack() konfigurácia nie je podporovaná. Musíte migrovať na turbopack.rules a turbopack.resolveAlias.
Turbopack má persistentnú cache v .next/cache/turbopack, ktorú treba zdieľať v CI pre plný efekt.
V monorepe s pnpm workspaces treba explicitne nastaviť turbopack.root, inak Turbopack pri deduplikácii modulov robí zbytočné duplicity.
Známe limity v 2026: chýbajúca podpora niekoľkých webpack loaderov, obmedzenia pri custom serveroch a niektoré CSS-in-JS knižnice vyžadujú SWC plugin.
Čo je Turbopack a prečo je v Next.js 16 dôležitý
Turbopack je inkrementálny bundler napísaný v Ruste, ktorý Vercel vyvíja ako priameho nástupcu Webpacku pre Next.js. Kľúčový rozdiel oproti Webpacku nie je len jazyk implementácie. Turbopack má funkčne odlišný model kompilácie postavený na jemnozrnnej dependency grafe a persistent memoization vrstve zdedenej z Turborepo enginu. V praxi to znamená, že pri malej zmene v jednom komponente Turbopack neinvaliduje celú vetvu grafu ako Webpack, ale prekompiluje len tie moduly, ktorých vstupy sa reálne zmenili.
V Next.js 15 bol Turbopack stabilný len pre next dev. Next.js 16 posunul produkčný build cez betu do stabilnej fázy a Vercel podľa release notes k Next.js 16 udáva 2× až 5× zrýchlenie oproti Webpacku, v závislosti od charakteru aplikácie. Pre staff-eng tímy, ktoré vlastnia build pipeline, je to prvýkrát moment, kedy prechod dáva reálny zmysel. Dev experience je konzistentný s produkciou a odpadá dvojfázové ladenie „funguje v dev, ale build to spadne”.
Ak vaša aplikácia už používa Server Actions v Next.js 16 a direktívu use cache, Turbopack je logický ďalší krok. Všetky tri veci sa v novom kompilátore správajú konzistentne a odpadá séria SWC/webpack transformov, ktoré si musíte drviť ručne.
Ako zapnúť Turbopack pre produkčné buildy
V Next.js 16 stačí do package.json pridať flag --turbopack k build skriptu alebo Turbopack povoliť priamo v next.config.ts. Osobne odporúčam druhú cestu, aby konfigurácia bola centralizovaná a nemuseli ste ju duplikovať naprieč dev, build a start skriptami.
// next.config.ts
import type { NextConfig } from 'next';
const config: NextConfig = {
// Turbopack je od Next.js 16 stabilný pre dev aj build.
// Ak vynecháte tento blok, Turbopack sa použije automaticky
// pre dev, ale build padne späť na Webpack.
turbopack: {
// Prázdny objekt = default nastavenia s aktívnym Turbopack build-om.
},
};
export default config;
Ak chcete Turbopack zapnúť len pre produkciu a v dev zostať na starom nastavení (napr. kvôli custom webpack loaderu, ktorý ešte neviete migrovať), použite ENV flag:
Toto je bod, kde padne najviac tímov. Turbopack nepodporujewebpack() callback v next.config.ts. Ak ho máte, build spadne s explicit chybou a nedovolí vám pokračovať s --turbopack. Nižšie sú tri najčastejšie migračné vzory z našej reálnej migrácie 34-package monorepa. (Áno, dvakrát som sa pri tom škriabala v hlave, kým som pochopila, čo Vercel s loaders vlastne myslí.)
1. Webpack loaders na turbopack.rules
Custom loadery pre SVG, MDX alebo GraphQL sa migrujú cez turbopack.rules. Turbopack podporuje väčšinu @svgr/webpack variantov aj klasické raw-loader reťazce.
Toto je bod, kde niektoré tímy dočasne zostávajú na Webpacku. Ak ste závislí na plugin ako @sentry/webpack-plugin pre source map upload, skontrolujte, či daný plugin ponúka Turbopack ekvivalent alebo Next.js build-time hook. Pre Sentry existuje @sentry/nextjs integrácia, ktorá tento krok robí cez Next.js build lifecycle a s Turbopack funguje bez konfigurácie.
Ako veľmi je Turbopack rýchlejší ako Webpack?
Reálne čísla z nášho SaaS monorepa (Next.js 16.0.4, pnpm 9.7, GitHub Actions ubuntu-latest-4-cores, aplikácia s ~1 400 modulmi, ~640 komponentmi, Tailwind + CSS Moduly, SVG cez svgr):
Metrika
Webpack (Next 15.4)
Turbopack (Next 16.0.4)
Zrýchlenie
Cold build (cache off)
4 min 12 s
1 min 09 s
3,65×
Warm build (cache on)
2 min 48 s
0 min 24 s
7,00×
Dev server pripravený
11,4 s
1,8 s
6,33×
HMR po zmene komponentu
820 ms
92 ms
8,91×
Peak RSS memory
3,1 GB
1,4 GB
2,21×
Route count v build outpute
218
218
1,00×
Dôležité poznámky k číslam: warm build s persistentnou cache je najreálnejší CI scenár, pretože v produkčnom pipeline si .next/cache reštorujeme z GitHub Actions cache akcie. Pri cold buildoch je rozdiel menší, pretože Turbopack aj Webpack musia od nuly analyzovať modul graph, ale Rust implementácia parseru a resolveru je stále rádovo rýchlejšia.
Peak memory pokles je pre veľké monorepá kritický. Na štandardnom GitHub runneri s 7 GB pamäte Webpack pri väčších aplikáciách hrozí OOM chybami. Turbopack má vlastný allocator a agresívnu deduplikáciu modulov, čo memory usage výrazne znižuje. (Na tento problém som narazila presne v marci minulého roka pri migrácii admin dashboardu, keď nám CI padal každý druhý PR na OOM.)
Turbopack v monorepe s pnpm a Turboreu
Ak vaša Next.js aplikácia žije v apps/web a package.json workspaces majú packages/*, musíte explicitne nastaviť Turbopack root. Inak Turbopack pri hľadaní node_modules vyskočí z workspace koreňa a začne duplikovať transitívne moduly z iných apps.
// apps/web/next.config.ts
import type { NextConfig } from 'next';
import path from 'node:path';
const config: NextConfig = {
turbopack: {
// Absolútna cesta k monorepo koreňu, nie k Next.js apps
root: path.join(__dirname, '../..'),
},
// Transpile shared packages, ktoré exportujú TSX
transpilePackages: ['@design-system/ui', '@design-system/tokens'],
};
export default config;
Turborepo integrácia funguje bez konfigurácie. turbo run build spustí next build so správnou cache, pretože Turborepo hashovaním workspace súborov ovláda Turbopack persistent cache výsledok. V našej pipeline sme skombinovali turbo run build --filter=@apps/web s GitHub Actions actions/cache pre .next/cache aj .turbo. Celkový build monorepa (5 Next.js apps, 12 shared packages) padol z 18 minút na 4 minúty 40 sekúnd. Úprimne, keď som prvýkrát videla ten graf v Datadogu, spýtala som sa kolegu, či niečo neprepočítal.
Problém s React duplikátmi v monorepe
Ak niektorý shared package má react v dependencies namiesto peerDependencies, Turbopack ho môže zbundlovať zvlášť a dostanete klasickú „Invalid hook call” chybu pri renderi. Fix je dvojkrokový: v shared package v package.json presunúť React do peerDependencies a v next.config.ts pridať resolveAlias ako v predchádzajúcom príklade. Na tento presný bug som stratila pol dňa, kým som pochopila, že chyba nie je v novom Reacte, ale v tom, že staršia verzia dizajn systému stále nebola opravená.
Aké má Turbopack limitácie v roku 2026?
Napriek stabilite Turbopacku pre produkčné buildy existuje niekoľko konkrétnych obmedzení, ktoré musíte poznať pred nasadením do CI:
Custom webpack loaders bez ekvivalentu. Loadery ako babel-loader s custom presets sú nepodporované. Turbopack má vlastný SWC-based transformer a Babel plugin ekosystém nemigroval kompletne.
CSS-in-JS knižnice. Styled-components a Emotion vyžadujú SWC plugin pre server rendering. V Next.js 16 sú tieto pluginy súčasťou next package, ale niektoré experimentálne CSS-in-JS knižnice (Vanilla Extract, Panda CSS) požadujú vlastnú konfiguráciu.
Custom Node.js server. Ak používate next start s custom server.ts súborom (Express, Fastify wrapper), Turbopack build funguje, ale runtime prepojenie je citlivé na verziu Node.js. Odporúčaná verzia je Node.js 20.11+ alebo 22 LTS.
Analyzer nástroje.@next/bundle-analyzer už podporuje Turbopack výstup, ale detailné statistiky per-chunk sú kratšie ako pri Webpacku. Pre hlbšiu analýzu použite next build --debug flag.
Neznámy edge case s dynamickými importmi z Node.js polyfillov. Ak importujete node:crypto alebo node:buffer v client komponente, Turbopack požaduje explicitnú konfiguráciu, nie tichý polyfill ako Webpack 5.
Persistentná cache a CI/CD
Najväčšiu výhodu Turbopack vytiahnete až vtedy, keď v CI zdieľate .next/cache/turbopack medzi bežmi. Vercel platform toto robí automaticky, ale ak stavate na GitHub Actions, GitLab CI alebo CircleCI, musíte cache nakonfigurovať explicitne. Cache je content-addressable a bezpečná na zdieľanie medzi PR bežmi.
Rozdiel medzi hashFiles na pnpm-lock.yaml a source súbory je dôležitý: prvý riadi coarse-grained cache invalidation (zmena dependencies), druhý fine-grained (zmena kódu). Turbopack persistent cache dokáže tak povedať „modul X sa nezmenil od posledného buildu” aj vtedy, keď sa zmenila iná časť aplikácie.
Pri nasadení odporúčam kombinovať Turbopack s Partial Prerendering v Next.js 16. Build vygeneruje statické shell HTML rýchlejšie a runtime cost je nižší, čo znižuje aj cold-start latency na Vercel edge. Presné konfiguračné referencie k build flagom sú v oficiálnej Turbopack referencii.
Ako debugovať pomalý Turbopack build
Ak Turbopack build v CI nie je taký rýchly, ako by mal byť, pridajte --debug flag a analyzujte NEXT_TURBOPACK_TRACING=1 output. Najčastejšie príčiny: chýbajúca .next/cache restore step v CI, appka bez output: 'standalone' pri Docker buildoch, alebo custom rewrites() hook, ktorý dynamicky číta zo súborového systému a invaliduje cache každý beh.
Časté otázky
Je Turbopack production ready v roku 2026?
Áno. Od Next.js 16 (november 2025) je Turbopack stabilný aj pre next build, nie len pre dev server. Vercel ho používa v produkcii na vlastnej platforme a zvyšný ekosystém (Sentry, GA, Auth.js) má Turbopack-kompatibilné integrácie.
O koľko je Turbopack rýchlejší ako Webpack?
Podľa Vercelu 2× až 5×, podľa nášho merania na monorepe s ~1 400 modulmi 3,65× pri cold cache a 7× pri warm cache. HMR je typicky 8 až 10× rýchlejší, pretože Turbopack invaliduje len skutočne zmenené moduly.
Musím prepísať webpack konfiguráciu pri prechode na Turbopack?
Ak máte custom webpack() callback v next.config.ts, áno. Loadery sa prepisujú na turbopack.rules, aliasy na turbopack.resolveAlias. Väčšina bežných konfigurácií (SVG, MDX, GraphQL, alias paths) má priamu ekvivalenciu.
Funguje Turbopack v monorepe s pnpm workspaces?
Áno, ale musíte nastaviť turbopack.root na absolútnu cestu k monorepo koreňu a shared React musí byť v peerDependencies shared packages. Turborepo integrácia je automatická.
Prečo môj build padá s „webpack is not supported” po zapnutí Turbopacku?
Máte v next.config.ts custom webpack() callback, ktorý Turbopack nevie interpretovať. Buď ho odstráňte, alebo migrujte na turbopack.rules/turbopack.resolveAlias. Chyba je zámerná, pretože Turbopack odmieta tichý fallback, aby ste netušili, že produkčný build ide inou cestou ako dev.
Praktický sprievodca Route Handlers v Next.js 16 App Routeri: HTTP metódy, cachovanie s use cache direktívou, Zod validácia, CORS v middleware, streaming, Edge vs Node.js runtime a playbook migrácie z pages/api.
Praktický sprievodca opravou hydratačných chýb v Next.js 16 s React DevTools, useEffect vzorom, dynamic importmi a suppressHydrationWarning. S ukážkami kódu.
Praktický sprievodca Server Actions v Next.js 16: ako písať formuláre s useActionState, validovať vstupy Zod-om, revalidovať cache a vyhnúť sa typickým bezpečnostným chybám v produkčnom kóde.
