Next.js 16.3 Preview — Feedback

[samselikoff]

Use this discussion to report any feedback or bugs you find in the 16.3 Preview release!

[jibin7jose]

Hi @samselikoff! Testing 16.3 Preview with Turbopack + output: "standalone" — found a real bug with turbopackIgnore.

Warning: Dynamic filesystem access causes tracing of the whole project

This cannot be silenced when a filesystem call receives a path.join(...) expression as its argument — even though the warning message itself recommends exactly that placement as the fix.

This has been originally reported here: #95125

Additional details

📁 Minimal Reproduction

// lib/loader.js
import fs from 'fs'
import path from 'path'

const folder = path.join(process.cwd(), 'data')

// ✅ WORKS — bare variable, comment silences warning
const files = fs.readdirSync(/* turbopackIgnore: true */ folder)

// ❌ STILL WARNS — no comment placement can silence this
const contents = files.map(f =>
  fs.readFileSync(path.join(folder, f), 'utf8')
)

// ❌ STILL WARNS — this is the EXACT form the warning recommends!
const contents2 = files.map(f =>
  fs.readFileSync(path.join(/* turbopackIgnore: true */ folder, f), 'utf8')
)

// ❌ STILL WARNS
const contents3 = files.map(f =>
  fs.readFileSync(/* turbopackIgnore: true */ path.join(folder, f), 'utf8')
)

Steps to reproduce:

1. Create the file above in a Next.js 16.3 canary project
2. Add output: 'standalone' to next.config.js
3. Run next build (default Turbopack)
4. Observe — readFileSync(path.join(...)) cannot be silenced

---

📊 Annotation Behavior Matrix

Annotation Placement	Result
readdirSync(/* turbopackIgnore: true */ folder)	✅ Silenced
readFileSync(/* turbopackIgnore: true */ path.join(folder, f))	❌ Still warns
readFileSync(path.join(/* turbopackIgnore: true */ folder, f))	❌ Still warns
readFileSync(path.join(folder, f)) — no comment	❌ Warns

The warning message says to use path.join(/*turbopackIgnore: true*/ process.cwd(), bar) —
but this form does not work for the outer readFileSync call.

---

🔍 Root Cause (Traced in Source)

After digging into the Turbopack source, the exact bug is in:

turbopack/crates/turbopack-ecmascript/src/references/mod.rs — line ~1554

// All call arguments are always linked with EMPTY ImportAttributes
// The `ignore` flag is NEVER passed down to argument expressions
let linked_args = || async {
    linked_args_cache.get_or_try_init(|| async {
        unlinked_args
            .iter()
            .map(|arg| arg.clone_in(state.arena.get_or_default()))
            .map(|arg| state.link_value(arg, ImportAttributes::empty_ref()))  // ← BUG
            .try_join()
            .await
    }).await
};

What this means:

• /* turbopackIgnore: true */ placed before a path.join(...) argument → the ignore flag is stored for the path.join call's own span
• When readFileSync evaluates its arguments, it uses ImportAttributes::empty_ref() (no ignore)
• The path.join(...) argument is evaluated as dynamic → FsReadMethod handler traces the whole project → warning emitted

The ignore flag only works on a bare variable (readdirSync(/* turbopackIgnore: true */ folder)) because that converts the function itself to Unknown, skipping the handler entirely.

---

💥 Why It Matters (Not Just Cosmetic)

This is a real deployment risk in these common cases:

1. Runtime-resolved data folders:

// You CANNOT silence this no matter what
const data = fs.readFileSync(path.join(process.cwd(), 'data', filename), 'utf8')

2. Libraries in node_modules (e.g. drizzle-orm's migrate()):

// Inside node_modules — you cannot add comments here at all
const files = fs.readdirSync(migrationsFolder)
files.map(f => fs.readFileSync(path.join(migrationsFolder, f)))

Result: The entire project — including the public/ folder — is traced into the standalone output. This can:

• Bloat deployment size significantly
• Cause deployment failures when serverless size limits are exceeded (Vercel, AWS Lambda, etc.)

---

🌍 Environment

Next.js	16.3.0-canary.65 (latest)
Builder	Turbopack (default)
Config	output: 'standalone'
Node	22.x
Platform	macOS arm64 / Windows x64

---

🔗 Related Issues

• Turbopack: turbopackIgnore doesn't silence the dynamic-fs whole-project trace for fs(path.join(...)) calls #95125 — Full bug report with reproduction repo and detailed code analysis
• Turbopack build: NFT warning "unexpected file" / next.config in trace with server routes reading fs outside app/ (outputFileTracingRoot) #92639 — Earlier report of same family (auto-closed for invalid repro link, never triaged)

---

✅ Expected Behavior

The /* turbopackIgnore: true */ placement shown in the warning message should actually suppress the trace — or the warning message should be updated to point to a placement that actually works.

---

💡 Proposed Fix Direction

In references/mod.rs, the FsReadMethod and FsReadDir handlers inside handle_well_known_function_call should:

1. Check attributes.ignore and return early (like handle_dynamic_import does at line ~1633)
2. OR propagate ignore status through argument linking so nested path.join calls are also suppressed

Happy to submit a PR if that would help! 🙏

[mdj-uk]

I love the new defaults with partialPrefetching, particularly runtime data being cached after navigation even without prefetching :-)

One thing I'm confused about: with partialPrefetching enabled, default prefetches (no prefetch prop on link, no prefetch segment config) seem to include content dependent on runtime data, e.g. cookies. Is that a bug?

Based on this from the docs I would not expect runtime data to be prefetched without configuring 'allow-runtime':

If the destination opts into prefetch = 'allow-runtime', the prefetch includes runtime data like cookies, headers, and search params.

demo / code

[icyJoseph]

IIRC, there's a docs correction coming up. The cookies are, so called, session data, and can be included in the prefetched App Shell. The docs already contain this info, I think we just mixed up with a recent change.

Thanks for looking at this early on too! We'll have a proper preview release ceremony soon-ish.

[mdj-uk]

Thanks, looking forward to the release

[GriffinSauce]

Hey @samselikoff - there are very good reports on dev build performance for Turbopack here. Everyone in that thread (and my team) is eagerly awaiting release!

[dmitri-gb]

I seem to have found a bug with Instant Insights. In my setup, I have a top-level loading.tsx file (/app/loading.tsx) that essentially makes every page "dynamic" (all pages stream and never block). This works fine, and I see the loading UI whenever I navigate to some page. However, Instant Insights doesn't seem to understand that the top-level loading.tsx applies to all pages, including child routes, and I get the Insights notification/popup whenever I navigate to /app/foobar/page.tsx or any other page apart from the top-level /app/page.tsx.

[icyJoseph]

Hi, thanks for giving this a go!

If I understand your description correctly, this is expected, and it is the kind of case Instant Insights helps developers with.

An /app/loading.tsx boundary does apply to the route tree below the root layout, that's correct. On a initial page load, you'd see the loading UI, given that there's uncached or runtime data in the destination page.

This is not the same for client navigations. On a client navigation, re-render doesn't necessarily happen from the root. It re-enters the tree at the shared layout boundary between the current route and the destination route. The root Suspense boundary be above that shared layout, and it is not used in that navigation.

That Instant Insight is letting you know that navigating into this route "blocks", because the route is likely accessing uncached data or runtime data access, and there's no the boundary in any of the shared layouts, to guarantee a instant UI. The dev overlay points exactly at what the issue is.

One possible fix is to Suspend there, but one could also use cache, it depends on your use case.

• https://preview.nextjs.org/docs/app/guides/instant-navigation#what-instant-means

[cpotey]

I might be missing something obviously, but think I've ran into a bug with meta titles (or maybe metadata in general) for built apps.

On a fresh load of a page with partialPrefetching: true, the meta title appears correct in the browser for me, but when navigating to another page it shows the url path as meta title (like https://connorpote.co.uk/about). If you refresh on that second page, the meta title appears again correctly like I'd expect with my various templates About | Connor Pote | Senior Front-end Engineer....

Example metadata I'm using on most of my pages atm:

export const metadata: Metadata = {
  title: "About",
  description: "blah blah blah",
  openGraph: {
    images: [
      {
        url: "/api/og?title=About",
        width: 1200,
        height: 630,
      },
    ],
  },
};

I've found that disabling partialPrefetching stops this metadata problem. Will probably look to disable this on my production release in a bit, only noticed it after releasing. This was not replicable in dev mode, only for the built/start app.

[pedro757]

I got this runtime error using react-email in preview.5

Error: Failed to load external module prettier-3c69a91af3bc4731/plugins/html: Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'prettier-3c69a91af3bc4731' imported from /var/task/apps/nextjs/.next/server/chunks/ssr/[turbopack]_runtime.js
    at Context.externalImport [as y] (.next/server/chunks/ssr/[turbopack]_runtime.js:616:15)
    at async (.next/server/chunks/ssr/[root-of-the-server]__0u01jw5._.js:1:54) {
  digest: '510432913'
}

prettier is only used as subdependency of react-email

BTW it does not error in canary.32

[icyJoseph]

What's the quickest way I could try to reproduce this? Do you already have a repository I could take a look at?

[akshatmittal]

Is partialPrefetching coming to static exports? Seems to require PPR at the moment which is incompatible with static outputs.