How to Fix: next package can’t be found when using –turbo and deno 2 rc in a monorepo

When Next.js suddenly becomes “not found” only when running –turbo with Deno 2 RC inside a monorepo, the failure usually is not in your app code at all. It is a package resolution mismatch between Deno’s newer workspace behavior, the monorepo layout, and how Next’s Turbopack startup expects the next package to be discoverable from the app boundary.

Understanding the Root Cause

This issue appears in setups like the reproduction repo because Deno 2 RC changed parts of dependency and workspace resolution behavior compared to earlier builds. In a monorepo, that matters because the Next.js app often depends on package discovery through the local package boundary rather than a flat, traditional Node-style installation.

When you run Next with –turbo, you are invoking Turbopack, which performs its own module resolution assumptions during startup. In this case, Turbopack expects the next package to be resolvable from the app’s own dependency graph. If the monorepo relies on hoisting, shared workspace installation, or Deno-managed resolution that does not materialize a package structure where Turbopack expects it, startup fails with a package-not-found error.

Technically, the problem is usually caused by one or more of these conditions:

• The app package does not declare next explicitly in its own package.json.
• Deno 2 RC resolves dependencies differently enough that a previously working hoisted dependency is no longer visible where next dev –turbo expects it.
• The monorepo uses a root-level dependency installation, but the Next app is executed from a nested workspace where node_modules visibility is inconsistent.
• Turbopack is less tolerant than the non-turbo dev server when dependency ownership is ambiguous.

So the real bug is not simply “Next is missing.” The real bug is that the app that runs Turbopack does not own a resolvable local Next dependency under Deno 2 RC’s package layout.

Step-by-Step Solution

The most reliable fix is to make the Next app explicitly own its runtime dependencies and ensure Deno installs them in a way that the app can resolve locally.

1. Add next, react, and react-dom to the app package

Open the package.json inside the Next app directory, not just the monorepo root.

{
  "name": "web",
  "private": true,
  "scripts": {
    "dev": "next dev --turbo",
    "build": "next build",
    "start": "next start"
  },
  "dependencies": {
    "next": "14.2.5",
    "react": "18.3.1",
    "react-dom": "18.3.1"
  }
}

If those packages exist only at the workspace root, move or duplicate them into the actual app package that runs Next.

2. Reinstall dependencies from a clean state

Clear generated dependency state so Deno rebuilds the package graph cleanly.

rm -rf node_modules
rm -f deno.lock
rm -f package-lock.json
rm -f pnpm-lock.yaml
rm -f yarn.lock

Then reinstall using the package manager strategy your repo actually uses. If the repo is driven through Deno’s Node compatibility workflow, run:

deno install

If your repo uses npm-style install commands for workspace packages, run that consistently from the repository root instead.

3. Ensure the app runs from its own workspace directory

Start the app from the package that contains the Next dependency.

cd apps/web
deno task dev

Or if your script is defined in package.json:

cd apps/web
deno run -A npm:next dev --turbo

The key is that the current working directory must match the package where next is declared.

4. Verify your workspace configuration

If you use a root package.json with workspaces, confirm the app is included correctly.

{
  "private": true,
  "workspaces": [
    "apps/*",
    "packages/*"
  ]
}

If you use deno.json or deno.jsonc, make sure task execution points into the correct app folder and does not assume root-level package visibility.

{
  "tasks": {
    "dev:web": "cd apps/web && deno run -A npm:next dev --turbo"
  }
}

5. Test without –turbo to confirm the scope of the bug

This is an important diagnostic step.

cd apps/web
deno run -A npm:next dev

If plain dev mode works but –turbo fails, that strongly confirms a Turbopack resolution issue rather than a general Next or React installation problem.

6. Pin to stable tooling if needed

If the issue started only after upgrading to Deno 2 RC, and explicit app-level dependencies do not fully solve it, pinning to a stable version is a practical short-term workaround until the Deno and Next interoperability stabilizes.

deno upgrade 1.45.5

Then retest the same workspace. If stable Deno works and RC fails, you have a strong compatibility signal for the underlying issue.

7. Practical known-good pattern

For monorepos using Next with Deno, the safest pattern is:

• Each runnable app declares its own runtime dependencies.
• Root workspace config manages orchestration, not hidden dependency ownership.
• next is installed where next dev –turbo is executed.
• Deno tasks change into the app directory before launching Next.

{
  "tasks": {
    "dev": "cd apps/web && deno task next-dev",
    "next-dev": "deno run -A npm:next dev --turbo"
  }
}

Common Edge Cases

1. The app depends on root-hoisted packages only

This is the most common monorepo mistake. It may work in one toolchain and fail in another. Turbopack is especially sensitive to whether the app directly owns next.

2. Mixed package managers

If the repo has traces of npm, pnpm, Yarn, and Deno-managed state at the same time, module resolution becomes unpredictable. Use one consistent install strategy and remove stale lockfiles.

3. Running commands from the repo root

Even when the workspace is configured correctly, launching Next from the wrong current directory can make resolution fail. In monorepos, cwd matters.

4. Symlink or workspace resolution differences on different operating systems

Some developers reproduce the issue only on one machine because package links and file system behavior differ across environments. Rebuilding dependency state from scratch often exposes whether this is happening.

5. Cached Deno package state

Deno may continue using cached package metadata after upgrades. If behavior looks inconsistent, clear cache and reinstall.

deno clean
rm -rf node_modules
rm -f deno.lock
deno install

6. Version mismatch between Next, React, and Deno compatibility layers

If you are testing a release candidate of Deno and a newer Next version at the same time, you may be hitting a compatibility gap rather than a repo-specific bug. Pinning known-good versions can help isolate it quickly.

FAQ

Why does Next work without –turbo but fail with it?

Because Turbopack uses a stricter or different resolution path during startup. A dependency graph that is barely tolerated in standard dev mode may fail when Turbopack tries to resolve next from the app boundary.

Do I really need to declare next inside the app if it already exists at the monorepo root?

Yes, in practice that is the safest fix. In monorepos, especially with Deno 2 RC and Turbo mode, relying on hoisted ownership can break package discovery. The runnable app should explicitly declare its own runtime dependencies.

Is this a Deno bug or a Next.js bug?

It is best described as an interop issue. Deno 2 RC changes package behavior, and Next’s –turbo path expects a resolvable dependency layout. The failure happens at the boundary between both systems, especially in monorepo workspace setups.

If you want the fastest path to green builds, make the Next app self-contained: declare next locally, reinstall cleanly, run from the app directory, and use stable Deno if RC behavior remains inconsistent. That resolves the issue in most monorepo setups matching the linked reproduction.