Next.js 16, Turbopack, and dependency conflicts with Bun

Next.js 16 plus Turbopack is faster, but stricter about dependency graph consistency. With Bun-based projects, that strictness often surfaces as package externalization errors during build.

1) Typical conflict scenario

Common stack in larger apps:

• Next.js 16 with Turbopack
• Bun 1.3.x
• Prisma 7
• deep dependency trees (jsdom, isomorphic-dompurify, email libs)

Frequent error:

Package agent-base can't be external. The package resolves to a different version...

2) Why this happens

Turbopack externalizes server-side packages. If different dependency branches resolve different versions of a shared subpackage, build determinism breaks.

3) Step-by-step fix

Step 1: deep cleanup

rm -rf .next node_modules bun.lock yarn.lock
bun pm cache rm

This removes stale lock/cache references.

Step 2: keep next.config.ts simple

Externalize top-level problematic packages, not every nested dependency:

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  reactCompiler: true,
  serverExternalPackages: [
    "prisma",
    "@prisma/client",
    "jsdom",
    "isomorphic-dompurify",
    "canvas",
  ],
};

export default nextConfig;

Step 3: force graph flattening with resolutions

If mismatch remains:

{
  "resolutions": {
    "agent-base": "7.1.4",
    "cssstyle": "5.3.7"
  }
}

Step 4: trust required postinstall scripts

Prisma and similar packages require postinstall steps:

bun install
bun pm trust --all
bun prisma generate

4) Dynamic imports and missing modules

Even with conditional await import(), Turbopack validates module availability at build time. Install optional providers that may be imported:

bun add resend @sendgrid/mail

For Next.js 16 on Bun, stable builds depend on:

1. clean lock/cache state
2. minimal serverExternalPackages
3. explicit resolutions for shared conflicts

With this setup, Turbopack becomes both fast and predictable in production.

This post is licensed under CC BY-NC.