turbopackIgnore Not Working? Fixed in Next.js 16.3

Last updated: August 2026

TL;DR

turbopackIgnore not working was a real bug. It was not user error.

GitHub issue #95125 tracked it. PR #95144 fixed it. That fix merged into canary on July 14, 2026. Next.js 16.3.0 went stable three weeks later, on August 3, 2026.

If you are on 16.3.0 or later, the fix should already apply. The annotation should work in the exact form the warning recommends. There is one gap the fix cannot close: code inside a node_modules dependency, like Drizzle's migrate(). For that case, skip the comment. Use outputFileTracingExcludes instead.

You add the comment. The warning says it will work.

It does not work.

You copy the exact line from the warning message. You rebuild. Same warning. Same file. Same line number.

You start Googling turbopackIgnore not working. You land on a two-month-old GitHub issue. No accepted answer. A PR you cannot tell has actually shipped.

Here is what was actually broken. Here is when it got fixed. Here is how to check your own build.

What the turbopackIgnore Warning Actually Means

Turbopack traces which files your server code touches. It uses that trace to build a minimal output: "standalone" bundle.

When it sees a dynamic call like readdirSync(folder), it cannot know which files that resolves to. Not at build time.

So it falls back. It traces your entire project into the output instead. That includes public/. Sometimes it includes .git. On Vercel or Lambda, that is exactly what triggers deployment-size failures - the same class of problem covered in Next.js Build Fails on Vercel, just from a different root cause.

The warning tells you how to opt out:

Turbopack build encountered 3 warnings:
./lib/loader.js:6:10
Warning: Dynamic filesystem access causes tracing of the whole project

To resolve this, you can
- make sure they are statically scoped to some subfolder, or
- only use them in development, or
- add ignore comments: path.join(/*turbopackIgnore: true*/ process.cwd(), bar), or
- remove them.

Most people reach for that third bullet. It is also the one that did not work.

The Bug: Why the Warning's Own Fix Failed

The warning flags the fs call itself. readdirSync. readFileSync. The suggested fix puts the annotation inside path.join instead. That is one level away from the thing that actually needs it.

Turbopack's comment parser only checked the direct argument to the fs function. A comment sitting inside a nested path.join() call never reached it. The exact code the warning printed did nothing. Every time.

The One Placement That Worked

There was a single working form. Annotate a bare variable, passed straight into the fs call.

javascript

// This silenced the warning, before the fix
readdirSync(/* turbopackIgnore: true */ folder);

That is not what the warning told you to write. People found it by trial and error, or by reading the GitHub issue directly.

What Still Failed Even Then

Even the working placement had a gap. A sibling call, readFileSync(path.join(folder, f), ...), kept warning no matter what. Before path.join, inside it, or on folder - nothing silenced it.

There was no documented placement that silenced that pattern. That is what got filed as issue #95125, on June 24, 2026, against next@16.3.0-canary.65. A full reproduction repo came attached.

When turbopackIgnore Was Actually Fixed

Next.js maintainer Luke Sandberg opened PR #95144 the same day. The fix does two things.

First, the warning now names the specific fs call, not the nearby path.join. Second, the comment detection got rewritten entirely. It now checks every expression in the call, not just the direct argument.

A turbopackIgnore comment now bubbles up through the whole chain. readFileSync(path.join(process.cwd(), someVar)) no longer needs two separate annotations in two places.

The PR merged into canary on July 14, 2026. Next.js 16.3.0 went stable on August 3, 2026 - three weeks later. Canary fixes normally flow straight into the next stable cut. If you are running 16.3.0 or newer, you very likely already have this fix.

One honest caveat: I have not personally reproduced this against a fresh 16.3.0 install. Treat the next section as your verification step. Not a promise. If your 16.3 build fails for a different reason entirely, check Next.js 16 cacheComponents Build OOM Fix - a separate, unrelated build-time issue from the same release line.

How to Verify Your Build Has the Fix

Do not take a blog post's word for this. Check it yourself.

Step 1. Confirm your installed version.

bash

npx next --version

You want 16.3.0 or later. On 16.2.x, or an older canary before 16.3.0-canary.76, the bug is still present.

Step 2. Reproduce the original pattern in a scratch file.

javascript

// lib/loader.js
import { readFileSync } from "fs";
import path from "path";

export function loadConfig(folder) {
  const f = "settings.json";
  return readFileSync(path.join(/* turbopackIgnore: true */ folder, f), "utf8");
}

Step 3. Run next build. Read the warning count. Before the fix, this exact pattern still triggered a whole-project trace warning. After it, that warning for this line should be gone.

Step 4. Check .next/standalone output size, before and after removing the dynamic call entirely. That confirms the annotation is doing real work. It rules out the warning going quiet for some unrelated reason. If you have not measured your own standalone output before, Prisma Docker Image Bloat: The v7 Fix walks through the same before/after measurement for a different tracing culprit.

Still seeing the warning on 16.3.0 or later? Open a fresh issue. Link back to #95125. That would mean the fix regressed somewhere between canary and your build.

The Case the Fix Still Cannot Solve: node_modules

The PR fixes annotation placement in your own code. It does nothing when the dynamic fs call lives inside a dependency you did not write.

The clearest example is Drizzle's migrate() function. It reads a migrations folder path at runtime. That is often required. The connection details and the migrations folder path are only known once the app boots. It boots on a runtime-mounted volume - Fly.io is a common example. That volume does not exist at build time.

You cannot add a comment inside node_modules/drizzle-orm/dist/migrator.js. Even if you did, the next npm install would erase it. This is a structural gap. It is not a bug the maintainers missed.

The Indirection Workaround, and Why It Falls Short

One option: wrap the dependency's read behind a function you control. Then annotate the wrapper instead.

This works when the dependency accepts a pre-resolved value. It does not work for Drizzle's migrate(). The file reads happen deep inside the library, not at a call site you control.

For that shape of problem, you need a config-level fix. Not a code-level one.

The Real Fix for node_modules: outputFileTracingExcludes

Next.js gives you a way to control the trace directly in next.config.js. This works independent of any comment.

javascript

// next.config.js
module.exports = {
  output: "standalone",
  outputFileTracingExcludes: {
    "*": [
      "./node_modules/drizzle-orm/**/*.map",
      "./public/large-assets/**/*",
    ],
  },
};

outputFileTracingExcludes takes a route glob as the key. The value is a list of project-root-relative globs, as documented in the official Next.js output configuration reference. Use "*" as the key to apply this everywhere. That is what you want for a dependency-level problem, not a single API route.

This will not stop the warning from printing during build. What it does is stop the excess files from actually landing in .next/standalone. That is the part that affects your deployment size.

Pair it with outputFileTracingIncludes if the trace is also missing files the dependency genuinely needs. Raw .sql migration files are a common example.

Key Takeaways

• turbopackIgnore not working, as the warning describes, was a confirmed bug. Issue #95125. Not a misuse of the feature.

• The bug was in comment placement detection. Annotations on path.join() were ignored. Only a bare variable, passed directly to the fs call, worked.

• The fix, PR #95144, merged to canary on July 14, 2026. It is very likely included in Next.js 16.3.0 stable, released August 3, 2026.

• Always confirm your own build. Run next --version and a minimal repro before trusting any blog post, including this one.

• The fix only covers code you can annotate. Dynamic fs calls inside node_modules, like Drizzle's migrate(), are still not fixable with a comment.

• For the node_modules case, use outputFileTracingExcludes in next.config.js. Do not try to annotate a dependency you cannot edit.

• --webpack suppresses the warning entirely. It is not a long-term option now that Turbopack is the default build tool.

FAQ

• Does turbopackIgnore still not work in Next.js 16.3?

  For the specific pattern in issue #95125, the fix merged into canary before 16.3.0 went stable. It should already be included. Confirm on your own install with next --version. The fix landed close to the stable cut date, so it pays to check.

• What version of Next.js fixed the turbopackIgnore bug?

  PR #95144 merged into the canary branch on July 14, 2026. Next.js 16.3.0 went stable on August 3, 2026. Any 16.3.0 build or later should carry the fix.

• Why did the warning message recommend a fix that didn't work?

  The warning pointed at path.join(), since that sits visually close to the flagged code. But the actual flagged operation was the fs function itself. The comment parser only checked the direct argument to that call. An annotation one level away, inside path.join(), was silently ignored.

• Can I disable the whole-project tracing warning in next.config.js?

  No flag turns off the warning itself. You can control which files end up in the traced output, using outputFileTracingExcludes and outputFileTracingIncludes. The warning may still print during build, even after you contain its effect.

• Does building with --webpack avoid this problem?

  Yes. The webpack build path does not produce this warning. That is not a real fix, though. Turbopack is now the default builder. --webpack is a legacy path, not a supported long-term workaround.

• How do I fix this for a dependency like Drizzle's migrate() that I can't edit?

  You cannot annotate code inside node_modules. Use outputFileTracingExcludes with a wildcard route key to strip unwanted files from the trace. Add outputFileTracingIncludes if the trace is missing files the dependency genuinely needs at runtime.

• Is this the same bug as issue #92639?

  Related, not identical. #92639 reported the same family of warning, under an older and vaguer message. It got closed for an invalid reproduction link. #95125 is the narrower, reproducible remainder, filed after Next.js improved the diagnostics.

• Will this bug come back in a future Turbopack update?

  Nothing rules that out for edge cases the fix did not cover. That is exactly why the verification steps above matter more than trusting a version number alone. Reproduce it against your own build before assuming you are covered.