Turbopack build failing in Next.js 16.3? Start here

If next build fails with Turbopack and succeeds with next build --webpack, the bundler is not broken. Something in the project is written for webpack, and Turbopack refuses it. Five causes cover almost every report, and four of them are fixable in an afternoon.

Turbopack is the Rust bundler that replaced webpack as the default in Next.js 16, so an upgraded project builds through it whether or not anyone chose it. webpack is the older JavaScript bundler that Next.js used by default until version 16, and it remains available behind a flag. That difference is why teams meet these failures during a routine version bump rather than during a planned bundler migration, as the Next.js 16 upgrade guide sets out.

Find the cause before you change the config

Run the build with more output first, because the five causes produce different errors and the wrong fix wastes a day.

1. Run next build --webpack once. If it passes, the failure is a Turbopack compatibility gap, not broken application code.
2. Delete .next and build again. A stale cache produces confusing errors, including missing _buildManifest.js.tmp files.
3. Read the first error, not the last. Turbopack reports the module that failed to resolve, and later errors are usually consequences.
4. Check whether the failure only happens in CI. That usually points at a restored cache or a case-sensitive filesystem.

Keep the result of step one. Whether webpack passes is the single most useful fact when you file a bug report.

Cause 1: a custom webpack loader that Turbopack never sees

The webpack() function in next.config.ts is ignored under Turbopack. Your loaders, aliases and plugins are silently absent, so imports that depended on them fail to resolve.

Translate loaders into the turbopack.rules configuration, and translate aliases into turbopack.resolveAlias, both documented in the Turbopack configuration reference. Both live under the top-level turbopack key, not under experimental. SVG imports through @svgr/webpack are the most common case, and they are also the easiest to convert.

Plugins are the harder problem. Turbopack has no plugin API, so a webpack plugin has no equivalent, and the work is to replace what the plugin did.

Cause 2: a dependency that only ships CommonJS

A package that publishes CommonJS with no ESM entry can break under Turbopack when its exports are read statically. The typical error names an export that "was not found in module", even though the export exists at runtime.

Three fixes work, in order of preference. Upgrade the package to a version with a proper exports map. Import the default export and destructure from it in your own code. Or, as the last resort, wrap the package in a small local module that re-exports what you need.

This is the same class of problem the JavaScript ecosystem has been working through for years, such as the module-format work behind faster toolchains that also drove the TypeScript 7 is 10x faster question. Turbopack is stricter than webpack, so it surfaces packaging mistakes webpack hid.

Cause 3: dynamic imports combined with cache components

Some builds fail on the combination of dynamic imports and cache components, which remains an open report against Next.js, tracked as issue 94456 in the vercel/next.js repository. The report was last updated on June 9, 2026 and is still open.

If your failure matches, isolate it before working around it. Convert one dynamic import to a static import and rebuild. When the build passes, you have a reproduction worth attaching to the issue.

The practical workaround is to make the imported boundary static in the route that fails, and to keep dynamic imports elsewhere. That costs a little bundle size on one route, which is cheaper than pinning the whole project to webpack.

Cause 4: path resolution that differs on Windows

Windows machines hit resolution failures that Linux and macOS do not, including an open report about failing to resolve package imports under Next.js 16, filed as issue 86431. It was last updated on July 1, 2026.

Next.js 16.3 shipped fixes in this area, including correct file URLs for import.meta.url on Windows and better worker_threads resolution, per the official Turbopack release notes. Upgrade before you debug, because you may be fixing something already fixed.

Case sensitivity causes the mirror-image bug. A build that passes on Windows and fails in CI usually contains an import whose capitalisation does not match the file on disk.

Cause 5: the React Compiler running through Babel

The React Compiler has shipped as a Babel transform, and on large applications that transform slows builds while it waits for JavaScript execution resources, according to the same Turbopack release notes. Slow builds become failed builds when a CI job hits its time limit.

The React Compiler is a build-time tool that adds memoisation to React components automatically, documented in the Next.js configuration reference. Next.js 16.3 adds an experimental native version. Enable reactCompiler: true and set experimental.turbopackRustReactCompiler: true to use the Rust port, which showed compilation wins of 20-50% on large React applications in early tests (Vercel, 2026).

Treat it as experimental in the exact sense. Turn it on in a branch, compare build times, and keep the Babel path available until a few builds have passed.

What the --webpack fallback costs you now

next build --webpack still works, and in Next.js 16.3 it costs more than it did a release ago. Falling back is a decision with a price tag, not a neutral escape hatch.

Feature in 16.3	With Turbopack	With --webpack
Persistent build cache in .next/cache	Enabled by default	Not available
Dev memory eviction	On by default	Not available
import.meta.glob	Supported	Does not work
Rust React Compiler	Experimental flag	Not available
Custom webpack plugins	No plugin API	Supported

The persistent build cache is Turbopack's on-disk store of previously compiled work, and it is enabled by default for next build in 16.3, as announced in the Next.js 16.3 release post. It is the line in the table that matters most for a team. Vercel measured its own site building in 9.2 seconds with a warm cache against 21 seconds cold, and one project dropped from 30 seconds to 5.5 seconds, per the release notes. Those gains disappear when you pass --webpack.

Make the cache actually work in CI

The Turbopack build cache lives in .next/cache, so continuous integration only benefits when that directory survives between runs. A fresh container starts cold every time.

1. Cache .next/cache in your CI configuration, keyed on the lockfile and the Next.js version.
2. Restore it before next build runs, not after install.
3. Invalidate it deliberately when you upgrade Next.js, since a mixed cache is worth less than a cold one.

Watch the cache size too. Consider a weekly clean job if the cache grows large enough to slow the restore step more than it speeds the build.

Upgrade, or wait?

Upgrade to 16.3 if you are on 16.x and your builds pass. The memory and build-time work is worth the version bump on its own, and Vercel reported dev server memory falling from 21.5 GB to 2 GB on its dashboard application after compiling 50 routes (Vercel, 2026).

Wait if you depend on webpack plugins with no Turbopack equivalent. Plan that migration as its own piece of work rather than doing it under a broken build during a release week. The same discipline applies to any toolchain jump, such as the one behind Rust 1.98 lands August 20, where a single change can break dependent crates.

Pin the exact Next.js version in your lockfile either way. A build that fails only on some machines is often a build running two different patch releases.