In a Next.js project, what is Turbopack, and what does running `next dev --turbopack` do differently from running the dev server on webpack?

## What a bundler does, and what Turbopack replaces A bundler is the tool that walks your import graph, applies transforms (TypeScript to JavaScript, JSX, CSS Modules, images), and emits the artifacts that actually run — the client chunks the browser downloads and the server code Next executes. Next.js did that with **webpack** for most of its life. Turbopack is the replacement, written in Rust by the Next.js team and shipped inside the `next` package: you do not install or configure it as a separate dependency. A common mix-up worth clearing early: **Turbopack is not Turborepo**. Turborepo is a monorepo task runner that caches and schedules `build`/`test`/`lint` commands across packages. Turbopack is the bundler inside one Next.js app. They share branding and nothing else. ## What the flag does ```bash next dev --turbopack # dev server on Turbopack next dev --webpack # dev server on webpack (Next 16 opt-out) next build --turbopack # production build on Turbopack ``` Running the dev server on Turbopack changes three things you can see immediately. Startup no longer compiles the whole application — the server comes up and compiles a route when you first request it. Edits are applied through a fast incremental update rather than a re-bundle of the affected chunk graph. And the terminal output is Turbopack's, so the familiar webpack compile lines are gone. In Next 16 Turbopack is the default bundler for both `next dev` and `next build`, so the `--turbopack` flag is a no-op there and `--webpack` is what you pass to go back. On earlier Next 15 releases the flag was how you opted in — dev first, builds later in the line. ## Why a second bundler at all webpack is JavaScript, so its work happens largely on one thread inside Node, and its caching is coarse-grained: a change tends to invalidate a whole module's downstream work. On applications with thousands of modules that produced dev servers taking tens of seconds to start and seconds to reflect a keystroke. Turbopack attacks both. Rust gives native execution speed and real parallelism across cores. Its engine caches individual units of compilation work keyed by their inputs, so after an edit it recomputes only the units whose inputs actually changed. And in development it is demand-driven — it never pays for routes you did not open. ## What does not change Switching bundlers is not a framework change. File conventions (`page`, `layout`, `loading`, `route`), Server Components, Server Actions, the caching layers and rendering modes behave identically. Code transforms still go through SWC, the same Rust compiler the webpack path already used via `next-swc`, so your TypeScript and JSX are handled the same way. Turbopack has built-in handling for CSS, CSS Modules, PostCSS (it reads a `postcss.config` file) and Sass when the `sass` package is installed. ## Where it bites The rough edge is customization. A `webpack(config)` function in `next.config` is only consulted by webpack — Turbopack ignores it, and Next warns rather than silently doing what you meant. Turbopack has its own `turbopack` config key with `rules` (a subset of webpack loaders), `resolveAlias` and `resolveExtensions`. There is **no webpack plugin API**, so anything shipped as a plugin needs a Turbopack-native equivalent or a different place in the pipeline. Turbopack also does not automatically switch to Babel when it finds a Babel config the way the webpack path did. For a plain App Router app with no custom bundler configuration — which is most new projects — none of that applies and the switch is invisible apart from the speed.