A Next.js app's `next.config.ts` has a custom `webpack()` function that adds an SVGR rule so `.svg` files import as React components. After the team switches to Turbopack, the rule stops applying. Why, and how do you express that rule for Turbopack?

## Why the rule silently stops applying `next.config` exposes a `webpack(config, context)` function whose whole purpose is to hand you webpack's configuration object so you can mutate it. That contract is bundler-specific by construction: the object is a webpack config, the rules you push are webpack `module.rules`, and the only thing that ever reads them is webpack. Turbopack does not consume that object. It is not a webpack-compatible bundler with a translation layer over the config — it is a separate implementation with its own configuration. So the SVGR rule is not misapplied or partially applied; it is simply never seen. Next detects the situation and warns that a custom webpack configuration is present while Turbopack is bundling, which is worth reading rather than scrolling past. ## The Turbopack configuration surface Turbopack's options live under a top-level `turbopack` key in `next.config` (it was previously nested under `experimental.turbo` before being promoted). The three you reach for most: - **`rules`** — an object keyed by glob, each value naming the loaders to run and what the result should be treated as. This is the port target for webpack `module.rules` entries. - **`resolveAlias`** — path aliases, the equivalent of webpack's `resolve.alias`. - **`resolveExtensions`** — the extension list tried during resolution. For the SVGR case: ```ts turbopack: { rules: { '*.svg': { loaders: ['@svgr/webpack'], as: '*.js' }, }, } ``` The `as` field tells Turbopack what the loader's output should be treated as — here, a JavaScript module, because SVGR turns the SVG into a React component. ## Loaders: a subset, not the ecosystem Turbopack implements the webpack loader interface well enough that many loaders run unmodified, and the popular ones generally do. But it is a subset. A loader that reaches into webpack internals — compilation objects, plugin hooks, webpack-specific APIs on the loader context — has nothing to reach for and will fail. When evaluating a migration, the question to ask about each loader is not "is it a webpack loader" but "does it stay inside the loader API." Before reaching for a loader at all, check whether you need one. Turbopack handles CSS, CSS Modules, PostCSS and Sass natively, plus the transforms Next already owns through SWC, so a good share of legacy `webpack()` blocks turn out to be re-implementing something now built in. ## Plugins: no equivalent exists This is the hard wall and the one worth naming explicitly in an interview. webpack's plugin API lets code hook arbitrary points of the compilation lifecycle, and a great deal of tooling is built on it — bundle manipulation, artifact generation, source-map upload to error trackers, custom asset emission. **Turbopack exposes no such API.** A webpack plugin cannot be ported by rewriting configuration; it needs either a Turbopack-native integration published by that tool, or the work moved somewhere else — a separate CLI step in CI, for instance. One more difference that catches teams: the webpack path in Next auto-detected a Babel config file and switched the transform pipeline to Babel. Turbopack does not do that. Custom Babel plugins are not picked up by their config file alone. ## Running the migration Keep both configuration blocks in `next.config` while you migrate. The `webpack()` function still applies whenever the bundler is webpack, so `--webpack` remains a working fallback, and `turbopack.rules` applies whenever Turbopack is bundling. Port one rule at a time, verify the imports it governs actually behave — an SVG rendering as a component rather than a URL string, for example — and delete the webpack block only once nothing runs on webpack any more.