Skip to content
Latchkey

Turbopack "Module not found: Can't resolve" - Fix next dev/build

Turbopack walked an import and could not resolve it. Beyond the usual missing-dependency and miscased-path causes, Turbopack does not read a custom webpack() config - alias and loader rules you added there are simply ignored, so a path that resolved under Webpack can fail under Turbopack.

What this error means

Running next dev --turbopack (or next build --turbopack) fails with Module not found: Can't resolve '<module>', often for a path or alias that worked with the Webpack compiler. It is deterministic and points at the import.

turbopack output
./app/dashboard/page.tsx:3:1
Module not found: Can't resolve '@/lib/format'

  1 | import { format } from '@/lib/format'
The module was not found in the Turbopack module graph.

Common causes

Alias defined only in webpack()

Turbopack ignores next.config webpack() customizations. An alias added via config.resolve.alias resolves under Webpack but is invisible to Turbopack, which reads turbopack.resolveAlias (and tsconfig paths) instead.

Dependency missing or path miscased

As with any bundler, the package may not be installed, or the path/case is wrong - Linux CI is case-sensitive where macOS is not.

How to fix it

Declare aliases where Turbopack reads them

Use tsconfig paths (which Turbopack honors) or the turbopack.resolveAlias config rather than a webpack() alias.

next.config.ts
// next.config.ts
export default {
  turbopack: {
    resolveAlias: { '@': './src' },
  },
}

Install the dependency and check the path

Terminal
npm install <package>
ls -la src/lib/format.ts   # exact case must match the import

How to prevent it

  • Prefer tsconfig paths for aliases so both Next compilers resolve them.
  • Do not rely on webpack() customizations when building with --turbopack.
  • Match import casing to filenames for case-sensitive runners.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →