I was wiring a Payload CMS project into a Next.js 15.5.4 app when the dev server started spamming Error: Could not find the module "[project]/src/components/admin/BackupFacebookPagesButton.tsx#default" in the React Client Manifest. The stack trace kept blaming the React Server Components bundler and the loop wouldn’t stop until the page crashed. After a long night of digging, I realized the conflict isn’t with our admin components at all—it’s Turbopack itself. This write-up documents exactly what went wrong, why the classic webpack compiler stays calm, and why I’m currently shipping with Turbopack turned off.
The Setup That Triggered the Error
The project uses Payload CMS 3.57.0 on top of Next.js 15.5.4. All dynamic pages render through src/app/(frontend)/[...slug]/page.tsx, which delegates to our shared Payload data layer in src/lib/payload/index.ts. Because Payload’s admin UI needs custom components, payload.config.ts references a generated import map at src/app/(payload)/admin/importMap.js. That map, in turn, statically imports several use client React components that only belong inside the admin dashboard.
The moment I ran pnpm dev --turbo and opened /home, the console flooded with React Client Manifest errors such as:
code
Error: Could not find the module "[project]/src/components/admin/CreateProjectFromPost.tsx#default" in the React Client Manifest
Switching to pnpm dev --no-turbo made the issue disappear entirely.
Reproducing the Manifest Loop Step-by-Step
Start the project with Turbopack.
bash
pnpm dev --turbo
Navigate to any frontend route handled by src/app/(frontend)/[...slug]/page.tsx (for example /home).
Observe the terminal and browser console: every admin import map entry explodes with Could not find the module "…#default" in the React Client Manifest. The loop repeats as Turbopack keeps retrying.
Stop the dev server, rerun with webpack, and notice the logs are clean:
bash
pnpm dev --no-turbo
Why Payload CMS + Turbopack Collide Here
The root cause is how Turbopack evaluates shared server modules. When the frontend page calls getPageBySlug from src/lib/payload/index.ts, Turbopack eagerly executes payload.config.ts to discover data dependencies. That config file pulls in the admin import map at src/app/(payload)/admin/importMap.js, and the import map eagerly imports every client-only admin widget, including:
Each of these files starts with "use client", so Turbopack expects to register corresponding client chunks. But the admin bundle never ships in the frontend build, so Turbopack never materializes those chunks. When the React Server Components runtime tries to serialize the response, it fails to find the client chunk metadata and throws the repeated error.
Webpack’s legacy compiler behaves differently—it tree-shakes imports when they belong to unreachable admin-only runtime branches. As a result, pnpm dev --no-turbo sidesteps the problem entirely.
Verifying That Admin Imports Are the Trigger
To confirm the hypothesis, I temporarily stripped the admin import map from the Payload config:
ts
// File: payload.config.tsexportdefaultbuildConfig({
admin: {
// importMap: { ... } // <-- Commented out for the experiment
},
// …rest of config
});
With that block disabled, pnpm dev --turbo stopped complaining. Restoring the import map brought the manifest loop back immediately, proving that Turbopack can’t currently tolerate Payload’s admin client imports when they live in shared configuration.
Current Workaround: Ship Without Turbopack
Once the investigation was done, I kept development stable by turning Turbopack off:
bash
pnpm dev --no-turbo
This falls back to webpack’s battle-tested compiler and eliminates the React Client Manifest loop. Production builds (pnpm build && pnpm start) already use the webpack pipeline, so nothing changes for deployment.
Waiting on a Real Fix
At the time of writing, the practical option is to develop with Turbopack disabled. Long term, we’ll either need Turbopack to respect Payload’s admin-only imports or refactor payload.config.ts so admin modules load lazily. Until then, the safest move is to stick to webpack whenever you see errors like:
code
Error: Could not find the module "[project]/node_modules/.pnpm/@payloadcms+richtext-lexical@3.57.0.../dist/exports/client/index.js#BlocksFeatureClient" in the React Client Manifest
Let me know in the comments if you’ve spotted a cleaner workaround, and subscribe for more practical development guides.
