Describe the Bug

Since upgrading from Next.js 15.4.4 → 15.5.0 (and still in 15.5.6 and partially on 16.0.1), running dev with Turbopack causes Payload Admin HMR to frequently fail with:

Error: Could not find the module "<path>#SomeClientComponent" in the React Client Manifest.
This is probably a bug in the React Server Components bundler.

The error appears after edits that affect Payload Admin (e.g., field/collection schema changes). It loops for many entries from admin/importMap.js, sometimes for 1–2 minutes, and either eventually compiles or crashes.

The FE HRM works; the failures hit the Admin route rebuild. If our code changes doesn't trigger Admin UI / data schema changes it works fine.

Example from logs on Payload Website Template when I removed test field from FormBlock config: (Next 15.5.x with SQLite)

 ✓ Compiled /admin/[[...segments]] in 153ms
 ○ Compiling /[slug] ...
Generating import map
No new imports found, skipping writing import map
[✓] Pulling schema from database...
? Warnings detected during schema push: 

· You're about to delete test_import_maps column in pages_blocks_form_block table with 1 items
· You're about to delete test_import_maps column in _pages_v_blocks_form_block table with 1 items

DATA LOSS WARNING: Possible data loss detected if schema is pushed.

Accept warnings and push schema to database? › (y/N) ✓ Compiled /[slug] in 1271ms
[⣷] Pulling schema from database...
[✓] Pulling schema from database...
✔ Warnings detected during schema push: 

· You're about to delete test_import_maps column in pages_blocks_form_block table with 1 items
· You're about to delete test_import_maps column in _pages_v_blocks_form_block table with 1 items

DATA LOSS WARNING: Possible data loss detected if schema is pushed.

Accept warnings and push schema to database? … yes
 ⨯ Error: Could not find the module "[project]/node_modules/.pnpm/@[email protected]_@[email protected][email protected]_react@19._79568805ff5ee287636170a598c47824/node_modules/@payloadcms/richtext-lexical/dist/exports/client/index.js#InlineToolbarFeatureClient" in the React Client Manifest. This is probably a bug in the React Server Components bundler.
    at stringify (<anonymous>) {
  digest: '1878333357'
}
 ⨯ Error: Could not find the module "[project]/node_modules/.pnpm/@[email protected]_@[email protected][email protected]_react@19._79568805ff5ee287636170a598c47824/node_modules/@payloadcms/richtext-lexical/dist/exports/client/index.js#FixedToolbarFeatureClient" in the React Client Manifest. This is probably a bug in the React Server Components bundler.
    at stringify (<anonymous>) {
  digest: '1906748461'
}
 ⨯ Error: Could not find the module "[project]/node_modules/.pnpm/@[email protected]_@[email protected][email protected]_react@19._79568805ff5ee287636170a598c47824/node_modules/@payloadcms/richtext-lexical/dist/exports/client/index.js#HeadingFeatureClient" in the React Client Manifest. This is probably a bug in the React Server Components bundler.
    at stringify (<anonymous>) {
  digest: '3441152301'
}
...

I initially suspected the dynamic regeneration of admin/importMap.js, but disabling auto-generation mportMap.autoGenerate produced the same behavior, so it’s not caused by the file changing during compile.

It looks like a race between Admin/FE/API compiles after file changes - Next’s logs show Turbopack compiling multiple routes concurrently. The issue began specifically with Next 15.5.0. In that release, Turbopack changed how it handles HMR after clearing the chunk cache - they removed code that delete From Require Cache the turbopack runtime (to fix memory leaks), and removed this TODO comment: Stop re-evaluating React Client once it relies on Turbopack's chunk cache.

PR: [turbopack] Clear chunk cache on HMR instead of creating new next-server VM (#81664) https://github.com/vercel/next.js/pull/81664/files

After this change, Admin’s client entries (many come from @payloadcms/richtext-lexical/client, @payloadcms/plugin-seo/client, and custom client UI in the import map) often aren’t present in the React Client Manifest at the time Admin is re-rendered during HMR.

With Next.js 16.0.1, behavior changes but seems related:

Admin HMR often does not recompile at all when adding new fields (no UI update; only a full dev server restart reflects changes).
On SQLite, removing a field triggers the migration prompt and does recompile Admin (and doesn’t error).
On MongoDB, no Admin HMR whether adding or removing fields; restart required.
If I trigger server restart via the (N) browser widget in Next 16 (in preferences), the same React Client Manifest errors resurface—suggesting the underlying Turbopack/manifest issue still exists; it’s just masked when Admin HMR doesn’t run.

In next 16.0.1 they still clear cache with next__clear_chunk_cache and the code is very similar to 15.5.0: https://github.com/vercel/next.js/blob/e08402bfad8db05b0df820daf4f08c9c65ab1f7b/packages/next/src/server/dev/hot-reloader-turbopack.ts#L388

So we have two probably related problems:

Next 15.5.x: Admin HMR triggers, but frequently fails with Client Manifest errors (likely due to Turbopack chunk cache clearing).
Next 16.0.1: Admin HMR often doesn’t run on schema additions; when Admin does rebuild (or after a restart), the same manifest errors can appear.

What I tried / findings

importMap.autoGenerate: false → same errors on Next 15.5.x.
Importing the admin/importMap.js at higher route level / in FE (dev-only) → didn’t prevent errors.
Using Webpack (next dev --no-turbo) → the issue does not occur.
Updated Node.js from 22 to 24, tested also on bun 1.3.1 - same issues. Runtime doesn't affect Turbopack here.
Updated Payload to 60.1 - same issues.
Next 16.0.1 still calls __turbopack_clear_chunk_cache__ in HMR codepaths; Admin HMR behavior seems changed (often not recompiling on schema add), but when the Admin does rebuild or after a restart, the same manifest errors occur.

Links giving more context:

Blog post analysis of this class of failures with Payload Admin import maps + Turbopack (not mine):
https://www.buildwithmatija.com/blog/payload-turbopack-react-client-manifest-error-debugging
Next.js PR that changed HMR behavior (15.5.0):
https://github.com/vercel/next.js/pull/81664/files
Discord discussion about this issue: https://discord.com/channels/967097582721572934/1409901645868961854

Link to the code that reproduces this issue

https://github.com/LucasMatuszewski/turbopack-error-reproduction

Reproduction Steps

Link to the code that reproduces this issue

Minimal reproductions (Payload Website Template + small changes):

Next 15.5.x + Payload 3.60.0 + SQLite (React Client Manifest errors on HMR):
- https://github.com/LucasMatuszewski/turbopack-error-reproduction
- Commit with changes vs original template: https://github.com/LucasMatuszewski/turbopack-error-reproduction/commit/070a35a0fb945c8636c2b9d0f131208403a870ff
Next 16.0.1 + SQLite (Admin HMR does not recompile on field add, does on remove after DB migration; no manifest errors, no Admin UI changes until restart) :
- https://github.com/LucasMatuszewski/turbopack-error-reproduction/tree/next-16-turbopack
- Commit with Codemod changes: https://github.com/LucasMatuszewski/turbopack-error-reproduction/commit/43a07fc86cd4993110a4638408b0b70e2c64f8d3
Next 16.0.1 + MongoDB + Payload 3.61.1 (Admin HMR does not recompile on add/remove; restart required; manifest errors can reappear after using Next.js web widget to restart server from the browser):
- https://github.com/LucasMatuszewski/turbopack-error-reproduction/tree/next-16-0-1%2Bmongodb%2BPayload-3-61-1
- Commit with changes: https://github.com/LucasMatuszewski/turbopack-error-reproduction/commit/6076b887fbebdcbe15cfe4894ca5d6185fc8b085

I used Website template instead of Blank, to have more components in importMap.js including custom components and with some FE only UI components. To test which changes trigger errors, and which doesn't.

Reproduction Steps

(Use repo 1 for Next 15.5.x behavior; 2/3 for Next 16.0.1.)

For all 3 cases below I did changes in Page Collection and Form Block config fields that you can find in this PR: https://github.com/LucasMatuszewski/turbopack-error-reproduction/commit/6555f73985ac959d233a42316d2c8fdc25280ec2

IMPORTANT: In my real app based on Next 15.5.6 & Payload 3.60.0 HMR sometimes work fine on 2-3 changes, and then suddenly I get these errors. Other time I get these errors immediately when I start the server or after first change in code. So please try multiple times if you didn't get these errors immediately.

For Next 15.5.x (repo 1):

pnpm i
pnpm dev (note: next dev --turbopack is in the script)
Open /admin, go to Contact Page
Edit a collection or field schema (e.g., remove or add a field in the Pages collection, Form Block).
Observe Turbopack HMR: Admin starts recompiling; within seconds, the console repeatedly prints “Could not find the module … in the React Client Manifest” for many entries from admin/importMap.js. Sometimes it compiles after a long loop; other times it crashes.

For Next 16.0.1 + SQLite (repo 2):

pnpm i
pnpm dev (Turbopack)
Open /admin, go to Contact Page
Add a new field to a collection → Admin UI usually does not update (no HMR). Refresh doesn’t help. Restart required.
Remove a field → Payload prompts DB migration; after accept, Admin HMR does rebuild and reflect change.
If you restart via the new (N) widget, the React Client Manifest errors may appear again.

For Next 16.0.1 + MongoDB (repo 3):

pnpm i
pnpm dev (Turbopack)
Open /admin, go to Contact Page
Edit a collection/field (add or remove) → Admin UI does not update via HMR. Restart required.
After restart, the manifest error can reappear

Which area(s) are affected?

area: core, area: templates

[x] Admin UI (import map / client components)
[x] Dev server / HMR
[x] Next.js adapter integration (Turbopack runtime)
[x] Client components in importMap.js (both plugins, core and custom components shows)
[x] Potential race condition when compiling Admin + FE + API concurrently

Environment Info

- OS: **Ubuntu 25.04**
- CPU: **Intel i7**
- Node.js: **22.16.0** and **24.11.0** + **Bun 1.3.1**
- pnpm: **10.15.0**
- Next.js:
  - **15.5.6** (regression starts at **15.5.0**)
  - **16.0.1** (different HMR behavior; underlying manifest error resurfaces after restart)
- React / react-dom: **19.1.0**
- Payload CMS: **3.60.0** (Next 15.5.x), **3.61.1** (Next 16 + Mongo)
- DBs tested:
  - **SQLite** (Payload’s `@payloadcms/db-sqlite`)
  - **MongoDB** (Payload 3.61.1 + mongoose adapter)
- Package manager: **pnpm**
- Dev script: `next dev --turbopack`

pnpm payload info - on Next.js 16.0.1, Payload 3.61.1 and Node 24.11.0

(I first tested on Next.js 15.5.6, Payload 3.60.0 and Node 22.14)

> [email protected] payload /home/lucas/DEV/Learning/PayloadCMS/turbopack-error-reproduction
> cross-env NODE_OPTIONS=--no-deprecation payload info

npm warn Unknown env config "enable-pre-post-scripts". This will stop working in the next major version of npm.
npm warn Unknown env config "verify-deps-before-run". This will stop working in the next major version of npm.
npm warn Unknown env config "_jsr-registry". This will stop working in the next major version of npm.
npm warn Unknown project config "enable-pre-post-scripts". This will stop working in the next major version of npm.
This project is configured to use pnpm because /home/lucas/DEV/Learning/PayloadCMS/turbopack-error-reproduction/package.json has a "packageManager" field

Binaries:
  Node: 24.11.0
  npm: 11.6.1
  Yarn: N/A
  pnpm: 10.15.0
Relevant Packages:
  payload: 3.61.1
  next: 16.0.1
  @payloadcms/db-mongodb: 3.61.1
  @payloadcms/email-nodemailer: 3.61.1
  @payloadcms/graphql: 3.61.1
  @payloadcms/live-preview: 3.61.1
  @payloadcms/live-preview-react: 3.61.1
  @payloadcms/next/utilities: 3.61.1
  @payloadcms/payload-cloud: 3.61.1
  @payloadcms/plugin-form-builder: 3.61.1
  @payloadcms/plugin-nested-docs: 3.61.1
  @payloadcms/plugin-redirects: 3.61.1
  @payloadcms/plugin-search: 3.61.1
  @payloadcms/plugin-seo: 3.61.1
  @payloadcms/richtext-lexical: 3.61.1
  @payloadcms/translations: 3.61.1
  @payloadcms/ui/shared: 3.61.1
  react: 19.2.0
  react-dom: 19.2.0
Operating System:
  Platform: linux
  Arch: x64
  Version: #34-Ubuntu SMP PREEMPT_DYNAMIC Wed Sep 17 09:21:29 UTC 2025
  Available memory (MB): 15240
  Available CPU cores: 12

Oct 30 '25 18:10 LucasMatuszewski

Same here. This has gotta be the best GH issue I've seen. Link to my repository; I've dockerized everything, so it's easy to run.

Nov 03 '25 04:11 drago1520

I'm running into this as well.

Also just want to say this is a great write-up, a very informative github issue, appreciate the effort put into it.

Nov 03 '25 04:11 rilrom

Thank you for this thorough report. We're looking into this one.

Nov 03 '25 14:11 denolfe

Thanks @drago1520 @rilrom @denolfe ! To be honest, I was trying to debug it myself for a few hours, with help of ChatGPT, and other AI tools. And in the end I just copied Payload's issue form and asked GPT-5 to provide Markdown with all the details :P

Dev server with Payload is very slow on my old laptop, i7 10th gen + 16GB RAM... So I have huge motivation to optimize it :D

Prod builds are also quite slow, even on Turbopack (very small difference, mostly because of simplified tracing). Both on my VPS and my laptop, with local DBs. I did some tests and provided screens and summary in this thread: https://x.com/mrLumatic/status/1985369038399094988

My App is based on Payload Website Template, but maybe I misconfigured something and it slows it down ;)

Nov 03 '25 19:11 LucasMatuszewski

+1 very annoying and you have to keep restarting dev server to temporarily fix the issue

Nov 04 '25 14:11 wayz9

Can you check if this is fixed in 3.63.0-internal.c0bd36f + Next.js 16.0.1?

Nov 05 '25 01:11 AlessioGr

Thank you so much! Upgraded all payload dependencies to 3.63.0-canary.5 and worked flawlessly! My repo

Nov 05 '25 09:11 drago1520

Thanks @AlessioGr - it fixed lack of HMR on changes in Payload Admin UI / data schema (I guess type vs action key in WS message was the main problem here).

But it did not fixed the Error: Could not find the module "X" in the React Client Manifest. This is probably a bug in the React Server Components bundler. - immediately after HMR trigger compilation I'm flooded with these errors for imports from importMap and it either crash or finally compile after 30-60s (so same as on Next.js >15.5.0).

I checked on 3.63.0-internal.c0bd36f as you pointed and on 3.63.0-canary.5.

I see you stopped throwing your own error in: https://github.com/payloadcms/payload/pull/14474/files#diff-394e358165e88ccb546bfe7252f70c539c683956dbd07c3ecd39e25568271653R32

But I never had that error: Could not find the import map file at ${importMapFile}${err instanceof Error && err?.message ? : ${err.message} : ''}

The error we see comes from Next.js' react-server-dom-turbopack probably from this file: https://github.com/vercel/next.js/blob/831534c163dc5602d68812022b17936b8d2dd00b/packages/next/src/compiled/react-server-dom-turbopack/cjs/react-server-dom-turbopack-server.browser.development.js#L215

As I described in the Issue, it happens on changes that trigger schema / Admin UI compilation - e.g. adding/removing fields in Page or Block config.

It happens when I have only Admin Panel open, so my FE app from (frontent) route group is not open anywhere. Based on your in-code comment your fix targeted the opposite situation (if we hit FE routes), but it's not this case:

    // This may run outside of the admin panel, e.g. in the user's frontend, where we don't have an import map file.
    // We don't want to throw an error in this case, as it would break the user's frontend.

If you are testing on blank template this issue may not happen. Please try on website template where we have more imports, plugins and custom Admin components in the importMap.js file.

It seams that the issue started after this commit in 15.5.0 (this part of code is very similar in 16.0.1): https://github.com/vercel/next.js/pull/81664/files

Nov 05 '25 13:11 LucasMatuszewski

@AlessioGr I'VE FOUND THE ISSUE! :D

TL;DR: Live preview is causing (frontend) route group compilation after (payload) compilation and Turbopack removes "unused" Client Modules from importMap.js that are not imported in (frontend) route group.

In my own app I've noticed that just after dev server start, when I only visit Admin UI with page from Pages collection: http://localhost:3000/admin/collections/pages/68fa3ddb5241be84a75f65e6

With Live Preview configured but CLOSED, I get in logs multiple paths compiled, including my FE app Page path on /pl/formularz-zapytania:

   ▲ Next.js 16.0.1 (Turbopack)
   - Local:        http://localhost:3000
   - Network:      http://192.168.86.37:3000
   - Environments: .env
   - Experiments (use with caution):
     · clientTraceMetadata
     · serverActions
     ✓ turbopackFileSystemCacheForDev

 ✓ Starting...
 ✓ Ready in 2.2s
 GET /admin/collections/pages/68fa3ddb5241be84a75f65e6 200 in 13.8s (compile: 3.2s, render: 10.7s)
 GET /manifest.webmanifest 200 in 201ms (compile: 177ms, render: 25ms)
 GET /next/preview?slug=formularz-zapytania&collection=pages&path=%2Fpl%2Fformularz-zapytania&locale=pl&previewSecret=xxxx 307 in 1899ms (compile: 239ms, render: 1660ms)
 GET /.well-known/appspecific/com.chrome.devtools.json 404 in 5.0s (compile: 4.0s, render: 964ms)
 GET /api/payload-preferences/collection-pages-68fa3ddb5241be84a75f65e6 200 in 4.0s (compile: 3.3s, render: 692ms)
 GET /api/payload-preferences/locale 200 in 4.0s (compile: 3.3s, render: 724ms)
 GET /api/users/me 200 in 3.4s (compile: 2.3s, render: 1093ms)
 GET /admin/collections/pages/68fa3ddb5241be84a75f65e6 200 in 4.4s (compile: 131ms, render: 4.3s)
 GET /api/payload-preferences/nav 200 in 502ms (compile: 130ms, render: 372ms)
 POST /api/reviews 200 in 391ms (compile: 7ms, render: 384ms)
 GET /api/payload-preferences/locale 200 in 463ms (compile: 157ms, render: 306ms)
 GET /manifest.webmanifest 200 in 15ms (compile: 9ms, render: 6ms)
 POST /api/forms 200 in 351ms (compile: 12ms, render: 339ms)
 GET /pl/formularz-zapytania 200 in 7.2s (compile: 5.8s, proxy.ts: 55ms, render: 1362ms)
 GET /api/users/me 200 in 1164ms (compile: 152ms, render: 1012ms)
 GET /api/users/me 200 in 1165ms (compile: 169ms, render: 996ms)
 GET /pl/formularz-zapytania 200 in 1563ms (compile: 286ms, proxy.ts: 20ms, render: 1256ms)

And immediately after I do some change in a field for Pages collection I get:

Generating import map
No new imports found, skipping writing import map
 ⨯ Error: Could not find the module "[project]/src/fields/CountChars.tsx#CountChars" in the React Client Manifest. This is probably a bug in the React Server Components bundler.
    at stringify (<anonymous>) {
  digest: '1401159352'
}
// 100+ times similar errors for imports from importMap.js, in the loop

I have live preview configured (but not open), so it triggers my FE app to build, when I only visit the Admin Panel for that page (without opening live preview).
- I see it's compiling /next/preview?slug=formularz-zapytania&collection=pages&path=%2Fpl%2Fformularz-zapytania&locale=pl&previewSecret=xxxx first,
- then it's compiling /pl/formularz-zapytania 2 times.
For one visit we get multiple duplicated requests to same paths. I see 10 unique paths compiled, most of them 2 times (probably because of default dev server debugging mode triggering duplicated renders, but in this case it may cause issues, some race conditions maybe)

To validate it I removed live preview, and all works fine, FE path is not compiled and no more errors:

 ✓ Starting...
 ✓ Ready in 3.9s
 GET /admin/collections/pages/68fa3ddb5241be84a75f65e6 200 in 14.0s (compile: 3.9s, render: 10.2s)
 GET /admin/collections/pages/68fa3ddb5241be84a75f65e6 200 in 2.9s (compile: 76ms, render: 2.8s)
 GET /manifest.webmanifest 200 in 144ms (compile: 126ms, render: 18ms)
 GET /.well-known/appspecific/com.chrome.devtools.json 404 in 4.4s (compile: 3.7s, render: 633ms)
 GET /api/payload-preferences/locale 200 in 1297ms (compile: 205ms, render: 1092ms)
 GET /api/payload-preferences/collection-pages-68fa3ddb5241be84a75f65e6 200 in 5.4s (compile: 4.0s, render: 1378ms)
 GET /api/payload-preferences/nav 200 in 1142ms (compile: 7ms, render: 1135ms)
 GET /api/users/me 200 in 1457ms (compile: 12ms, render: 1446ms)
 GET /admin/collections/pages/68fa3ddb5241be84a75f65e6 200 in 6.7s (compile: 237ms, render: 6.5s)
 POST /api/reviews 200 in 470ms (compile: 78ms, render: 392ms)
 GET /api/payload-preferences/locale 200 in 589ms (compile: 189ms, render: 400ms)
 GET /manifest.webmanifest 200 in 14ms (compile: 5ms, render: 9ms)
 POST /api/forms 200 in 285ms (compile: 8ms, render: 277ms)

// I added a new field to Page collection

 ✓ Compiled in 825ms
Generating import map
No new imports found, skipping writing import map
Generating import map
No new imports found, skipping writing import map
 GET /admin/collections/pages/68fa3ddb5241be84a75f65e6 200 in 8.5s (compile: 924ms, render: 7.6s)
 GET /admin/collections/pages/68fa3ddb5241be84a75f65e6 200 in 7.1s (compile: 14ms, render: 7.0s)
 GET /manifest.webmanifest 200 in 13ms (compile: 4ms, render: 9ms)
 GET /api/payload-preferences/locale 200 in 985ms (compile: 688ms, render: 297ms)

So the issue happens when Trubopack compiles both FE app from (frontent) group (that doesn't import importMap.js) and Admin from (payload) group (that imports importMap.js).

Probably the cache optimizations Next.js introduced in 15.5.0 to prevent memory leaks removes "unused" modules from React Client Manifest when the FE path starts compilation because my /pl/formularz-zapytania path was compiled as the last one. And when we change something in schema Payload app tries to compile changes in the Pages collection as in my logs: GET /admin/collections/pages/68fa3ddb5241be84a75f65e6 200 in 8.5s (compile: 924ms, render: 7.6s

But in case of routes where we have live preview (FE was compiled as the last path) these modules are removed by Turbopack to "prevent memory leaks" as they described this ;)

Quick dirty fix would be to prevent FE paths compiling when we don't have Live preview open.

But it will not fix the issue when we actually want to use live preview in dev or if we have our FE app open in separate tab. (tested this, if I open FE path after admin compilation, and then make some change in data schema I have same errors because FE path compilation removed Client Modules from Manifest)

So we need to find a way to either:

prevent Turbopack removing modules from importMap.js when the FE app from (frontend) is compiled
load modules from importMap.js again before Payload tries to compile collection data (you can probably trigger this as dynamic import() or something)

Alternatively we can probably also just import importMap.js in our FE layout.ts (conditionally in development env only)

Nov 05 '25 14:11 LucasMatuszewski

After analyses of Next.js code, I have the feeling that it's a bug in Next.js and not sure if we can fix it on our side.

To prevent "memory leaks" they keep clearing Turbopack cache but stopped removing reference to client module paths from Node.js runtime: https://github.com/vercel/next.js/pull/81664/files

What's happening:

on route group change (payload) --> (frontend) Next.js perform full page load so they invoke __turbopack_clear_chunk_cache__() that is pointing to Turbopack binary addon = Rust code clearing internal Turbopack cache (including compiled modules from importMap.js),
before 15.5.0 they used to clear cache also for Node.js runtime next/dist/compiled/next-server/app-page-turbo.runtime.dev.js but it forced full re-evaluation and memory leaks, so they just removed this code = reference to module paths from importMap.js is still in Node.js cache, but modules are not in Turbopack cache anymore,
when we trigger HMR compilation in (payload) route group Turbopack hits /admin/collections/... route and reads var modulePath = clientReference.$$id, for all client modules that were not removed from Node.js cache,
then they try to resolve each module by modulePath from config (Turbopack's compiled modules) here resolvedModuleData = config[modulePath.slice(0, idx)] but module is not longer in Turbopack cache, so they throw these errors.

It's in this code (also on 16.0.1): https://github.com/vercel/next.js/blob/canary/packages/next/src/compiled/react-server-dom-turbopack/cjs/react-server-dom-turbopack-server.browser.development.js#L215

IMHO they forgot that some people may use pages from both route groups in the same time... I'm sure it's not only Payload's issue... To prevent memory leaks they should implement some smarter way to either clear Turbopack cache only for specific paths or to remove Node.js reference to modules from other route groups without restarting whole runtime...

Maybe there is some config to prevent Turbopack from removing some modules? Or they should add one. Currently I only see resolveAlias and resolveExtensions in docs: https://nextjs.org/docs/app/api-reference/turbopack#configuration

@AlessioGr - please let me know if you see any way you can fix it on your side? Or maybe you have some good contacts in Next.js team @denolfe and prefer to discuss it with them directly first? If not, I can create an issue on Next.js repo explaining everything.

Temporary fix

I've found partial dirty fix that makes the issue less annoying in development.

You can create a new root /app/layout.ts file that only imports importMap (but don't use it!):

import { ReactNode } from 'react';

type Props = {
  children: ReactNode;
};
export default async function RootLayout({ children }: Props) {
  // Dynamic import in root /app/layout.ts to re-import on each render
  await import('./(payload)/admin/importMap');

  return children;
}

Not sure why, but it makes the path from (frontend) route group to compile first, so when I make some changes that trigger HMR compilation in (payload) route group I first see my /pl/formularz-zapytania route compiled, and I get some errors for ONE missing /error.tsx module from my code, but it's only 5-10 times (not >150 times), so after few seconds page compiles. So it's enough to make Turbopack keep these modules compiled (or compile them again).

After this change I see in my logs:

 POST /api/reviews 200 in 334ms (compile: 10ms, render: 324ms)
 POST /api/forms 200 in 313ms (compile: 8ms, render: 306ms)
// previous compilation fully finished above ^^^^

// I make some change in Page Collection config

 ✓ Compiled in 104ms // <-- THIS TIME IT COMPILED immediately (before it didn't)

Generating import map
No new imports found, skipping writing import map
Generating import map
No new imports found, skipping writing import map
 ⨯ Error: Could not find the module "[project]/src/app/(frontend)/[locale]/error.tsx#default" in the React Client Manifest. This is probably a bug in the React Server Components bundler.
    at stringify (<anonymous>)
    at stringify (<anonymous>) {
  digest: '3033085638'
}
// same error 5-10 times

// my (frontend) route is compiled first (before admin route was first):
 GET /pl/formularz-zapytania 200 in 19.2s (compile: 38ms, proxy.ts: 12ms, render: 19.2s)
 GET /pl/formularz-zapytania 200 in 23.6s (compile: 3.3s, proxy.ts: 13ms, render: 20.3s)
 GET /pl/formularz-zapytania 200 in 19.9s (compile: 54ms, proxy.ts: 17ms, render: 19.8s)
 GET /admin/collections/pages/68fa3ddb5241be84a75f65e6 200 in 19.1s (compile: 16ms, render: 19.1s)
 GET /admin/collections/pages/68fa3ddb5241be84a75f65e6 200 in 19.9s (compile: 496ms, render: 19.4s)
 GET /admin/collections/pages/68fa3ddb5241be84a75f65e6 200 in 23.7s (compile: 675ms, render: 23.0s)
 GET /manifest.webmanifest 200 in 12ms (compile: 7ms, render: 5ms)
 GET /api/payload-preferences/locale 200 in 595ms (compile: 309ms, render: 285ms)
// Admin path fully renders, not perfect but HMR "works"

I also tried to use imported importMap object (e.g. console.log keys or add it to window) but it triggers Mongoose errors:

 ⨯ OverwriteModelError: Cannot overwrite `_categories_versions` model once compiled.
    at async (src/utils/getSettings.ts:11:19)
    at async LayoutBase (src/components/LayoutBase/LayoutBase.tsx:22:20)
   9 |  */
  10 | export const getSettings = cache(async () => {
> 11 |   const payload = await getPayload({ config: configPromise });
     |                   ^
  12 |
  13 |   try {
  14 |     const settings = await payload.findGlobal({ {
  digest: '149680905'
}

Probably when importMap is used in some way it triggers compilation of Payload modules from importMap that use Mongoose internally so Mongoose model was already compiled when my FE code tries to use getPayload(). Fortunately importing without using is enough to keep modules in Turbopack.

I tried also dynamic imports in (payload)/layout.ts, but it didn't work (we need these modules on the server during compilation time, dynamic import probably only loads them for React, too late). Same with importing importMaps in (frontent) route - didn't work.

Nov 05 '25 22:11 LucasMatuszewski

@LucasMatuszewski thank you a lot for this detailed issue and your research! This might be resolved by https://github.com/payloadcms/payload/pull/14502. Could you test out the following pre-release and let me know if that fixes it? 3.63.0-internal.15444aa

The problem seems to happen if we just access the import map using fs while HMR is running and there are 2+ getPayload listeners, even if we don't write to it

Nov 06 '25 03:11 AlessioGr

Thanks @AlessioGr - I tried it both on my prod app and on website template and in both cases I still have these errors when I edit fields that changes schema and trigger HRM in MongoDB. But a little less than before.

In your PR's video you added custom component, and I guess it doesn't change data schema, so maybe in this case it works fine. But pls add new field in Pages collection.

The number of errors is reduced a little bit, probably because you skip duplicated compilation for Payload modules when cached.reload instanceof Promise. On website template I get only 18 errors, but in my prod app it's 91, still not usable.

And now I get 'Compiled' first and 'Generating import map + errors' after compilation (setTimeout changed the order):

 ✓ Compiled in 105ms
Generating import map
No new imports found, skipping writing import map
 ⨯ Error: Could not find the module "[project]/node_modules/.pnpm/@[email protected]_@[email protected]_react-dom_7dee8ae828492beaf1a544eeeec801c6/node_modules/@payloadcms/richtext-lexical/dist/exports/client/index.js#InlineToolbarFeatureClient" in the React Client Manifest. This is probably a bug in the React Server Components bundler.
    at stringify (<anonymous>) {
  digest: '396736961'
}
// 18 Errors on Website Template, 91 in my prod app (instead of >150 times before)

So your PR mitigated the issue a little bit! Thank you :)

But still:

I got these errors immediately after server start on ○ Compiling /admin/[[...segments]] ... (not always)
I got them again when I added a new field in Pages collection.

The root issue is still in Next.js clearing cache in Turbopack but not in Node.js when we have full page load on route group change between (frontend) <--> (payload):

 ⨯ Error: Could not find the module "[project]/src/Footer/RowLabel.tsx#RowLabel" in the React Client Manifest. This is probably a bug in the React Server Components bundler.
    at stringify (<anonymous>) {
  digest: '3253779777'
}
 GET /contact 200 in 290ms (compile: 107ms, render: 184ms)
 GET /contact 200 in 11.1s (compile: 452ms, render: 10.7s)
 GET /admin/collections/pages/69037f508f848bb39f9b09ff 200 in 12.7s (compile: 390ms, render: 12.3s)
 GET /admin/collections/pages/69037f508f848bb39f9b09ff 200 in 1055ms (compile: 178ms, render: 877ms)

But not sure if you can do anything more than you did. It's already better. Thank you!

But still my "dirty hack" with /app/layout.ts dynamic import works better in my case.

Reproduction for Website Template with your latest internal release + Mongo is here: https://github.com/LucasMatuszewski/turbopack-error-reproduction/tree/next-16-0-1%2Bmongodb%2BPayload-3-63-0-internal-1544aa

Nov 06 '25 11:11 LucasMatuszewski

I’m not sure if this information is relevant, but I’m experiencing the same issue even with live preview disabled, using only the direct preview links.

Nov 07 '25 09:11 timothylp

🚀 This is included in version v3.63.0

Nov 07 '25 15:11 github-actions[bot]

this is happening on 3.63.0 for me

Nov 10 '25 16:11 giorgiPapava

it is very annoying that i need to restart server almost everytime. is there any temp fix?

Nov 14 '25 09:11 giorgiPapava

it is very annoying that i need to restart server almost everytime. is there any temp fix?

it worked on 3.63.0-internal.c0bd36f, repo > https://github.com/drago1520/payloadcms-speed-test-next16-from-scratch.git

Nov 14 '25 09:11 drago1520

it is very annoying that i need to restart server almost everytime. is there any temp fix?

it worked on 3.63.0-internal.c0bd36f, repo > https://github.com/drago1520/payloadcms-speed-test-next16-from-scratch.git

it is happening on 3.64.0 for me

Nov 14 '25 10:11 giorgiPapava

Until this get solved, there's no way to use PPR with Next.js because it requires next@canary and it installs Next.js +16

Is there any workaround?

I'm being able to use the dev server but builds fail with an error bigger than what my terminal can show

Nov 17 '25 21:11 bmarianome

I do not understand bundlers etc in any kind of depth, it was annoying to get these errors with Next 16.0.3 (latest) upgrade. From Next docs, it seems like turbopack is default enabled now. I just added --webpack option to the package.json dev and build scripts to disable turbopack in dev by default and it has helped fix the issues and with not having to restart the dev server. Hopefully this helps as a stop gap while the issue is fixed.

Nov 17 '25 22:11 ritesht

Still happening on 3.65.0

Nov 26 '25 11:11 Crustan

This just got merged, might be worth checking out

https://github.com/vercel/next.js/pull/86591 👀 @AlessioGr

Dec 01 '25 15:12 wayz9

Closing, as this was fixed in the latest Next.js 16 canary

Dec 08 '25 00:12 AlessioGr

Turbopack HMR - Error: Could not find the module X in the React Client Manifest (Next.js 15.5.0 and 16.0.1)

Describe the Bug

What I tried / findings

Link to the code that reproduces this issue

Reproduction Steps

Link to the code that reproduces this issue

Reproduction Steps

Which area(s) are affected?

Environment Info

pnpm payload info - on Next.js 16.0.1, Payload 3.61.1 and Node 24.11.0