How to Fix: `next dev –turbo` error when using `bun.lock` text lockfile

next dev –turbo can fail in a Turborepo when the workspace uses Bun’s text-based bun.lock because Next.js Turbopack expects lockfile parsing behavior that does not match that format in affected versions. The result is a development server crash even though the repository installs and runs correctly with other package manager setups.

What the bug looks like

This issue appears when you create a new monorepo with Bun, keep the text lockfile, and then start a Next.js app with next dev –turbo. In the affected setup, standard dependency installation succeeds, but the Turbopack dev server breaks during startup.

The reproduction linked in the issue uses a Turborepo created with this repository. The failure is specifically tied to the interaction between Next.js, Turbopack, and Bun’s lockfile format rather than to application code.

Understanding the Root Cause

The root of the bug is lockfile format compatibility. Next.js, especially when running –turbo, uses dependency graph information to optimize module resolution, caching, and workspace analysis. In a monorepo, that process often depends on reading the package manager lockfile to understand package relationships.

Older or affected Next.js/Turbopack code paths handle common lockfile formats such as package-lock.json, pnpm-lock.yaml, and yarn.lock more reliably than Bun’s newer text bun.lock format. When Turbopack attempts to parse or infer workspace package state from that file, it can fail because:

• The parser may expect a different Bun lockfile representation.
• The monorepo dependency graph may be derived from lockfile semantics Turbopack does not fully support in that version.
• Workspace package linking can be misdetected, causing resolution or startup failures in dev mode only.

This is why the bug often appears with next dev –turbo but not necessarily with plain next dev. The non-Turbopack path uses different internals and may avoid the unsupported lockfile parsing path entirely.

Step-by-Step Solution

The safest workaround is to avoid Bun’s text lockfile for the affected Next.js version, or avoid Turbopack until support is fixed upstream. Use one of the following solutions.

Option 1: Run Next.js without Turbopack

If you need Bun but do not strictly need Turbopack, remove the –turbo flag from your dev script.

# apps/web/package.json or equivalent scripts section before change
"dev": "next dev --turbo"

# after change
"dev": "next dev"

Then restart the app:

bun run dev

This is the fastest workaround if your goal is to keep local development unblocked.

Option 2: Use a supported lockfile and package manager for dev

If you want to continue using Turbopack, switch the workspace to a lockfile format that Next.js handles more consistently.

Example using pnpm:

# remove Bun lockfile
rm bun.lock

# if node_modules already exists, clean it
rm -rf node_modules apps/web/node_modules packages/*/node_modules

# enable and use pnpm
corepack enable
pnpm install
pnpm --filter web dev -- --turbo

Example using npm:

rm bun.lock
rm -rf node_modules package-lock.json
npm install
npm run dev --workspace=web -- --turbo

This works because the workspace dependency graph is rebuilt using a lockfile format Turbopack is more likely to understand correctly.

Option 3: Configure Bun to generate the compatible lockfile format if available in your setup

Depending on your Bun version and team constraints, you may be able to avoid the problematic text lockfile mode and use the lockfile format expected by your toolchain. If your organization standardizes on Bun, check the Bun documentation and your current version behavior before regenerating the lockfile.

# remove current artifacts
rm -rf node_modules bun.lock

# reinstall dependencies with your team's chosen Bun settings
bun install

After reinstalling, rerun:

bun run dev

If the generated lockfile is still the text variant and the error remains, use Option 1 or 2.

Option 4: Upgrade Next.js, Turbopack, and Bun

If the bug has been fixed upstream, upgrading is the cleanest long-term solution.

# with bun
bun add next@latest react@latest react-dom@latest

# or with pnpm
pnpm up next react react-dom

Also update Bun itself to the latest stable release, then reinstall dependencies and test again. Compatibility bugs around lockfiles are often fixed in either the framework or package manager parser.

Recommended team-safe fix

For shared monorepos, the most predictable approach is:

1. Pick one package manager for the repository.
2. Commit only one lockfile.
3. Use next dev instead of next dev –turbo until your exact Next.js + Bun combination is confirmed to work.

# package.json
{
  "packageManager": "pnpm@9.0.0",
  "scripts": {
    "dev": "turbo run dev"
  }
}

This reduces cross-tool lockfile ambiguity and prevents inconsistent local setups across contributors and CI.

Common Edge Cases

1. Multiple lockfiles in the repo

If the repository contains bun.lock, pnpm-lock.yaml, and package-lock.json at the same time, tooling may detect the wrong package manager. Remove unused lockfiles and reinstall dependencies from scratch.

find . -maxdepth 2 \( -name "bun.lock" -o -name "pnpm-lock.yaml" -o -name "package-lock.json" -o -name "yarn.lock" \)

2. Turborepo cache keeps stale state

Even after changing package managers, the cached graph may still reflect the old dependency layout. Clear cache directories before retesting.

rm -rf .turbo
rm -rf apps/web/.next
rm -rf node_modules

3. CI works but local dev fails

This usually means CI is using a different package manager or lockfile than your workstation. Compare the committed lockfile, the packageManager field in package.json, and the Bun version installed locally.

4. Bun installs fine, but only one app in the monorepo crashes

That often points to a workspace-specific resolution path. Check whether the failing app is the only package using next dev –turbo or relies on local packages with transitive dependencies that Turbopack must inspect.

5. Upgrade did not help

If the issue persists after upgrading, verify that the old lockfile was fully removed and regenerated. Some teams accidentally keep a stale lockfile in a subdirectory, which continues to trigger the bug.

FAQ

Does this bug mean Bun is unsupported by Next.js?

No. It usually means a specific combination of Next.js version, Turbopack, monorepo layout, and bun.lock text format is unsupported or buggy. Bun itself may still work for installs, scripts, or non-Turbopack workflows.

Why does next dev work while next dev –turbo fails?

Because Turbopack uses a different development pipeline and dependency analysis path. The unsupported lockfile handling is often only exercised when –turbo is enabled.

Should I switch the whole monorepo away from Bun?

Not necessarily. If your team depends on Bun, the practical short-term fix is to disable –turbo for local Next.js development. If Turbopack is important to your workflow, using pnpm or npm for that repository may be the more stable option until upstream support improves.

In short, this bug is not caused by your application code. It is a tooling compatibility issue between Next.js Turbopack and Bun’s text lockfile. The fastest workaround is to remove –turbo. The most reliable monorepo fix is to standardize on a lockfile format Turbopack fully supports, clean caches, reinstall dependencies, and retest.