Fix Turbopack React Client Manifest Errors with Payload CMS Admin Import Maps
Why Turbopack loops on admin-only client imports and how to ship safely today

📚 Comprehensive Payload CMS Guides
Detailed Payload guides with field configuration examples, custom components, and workflow optimization tips to speed up your CMS development process.
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:
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.
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:
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:
src/components/admin/BackupFacebookPagesButton.tsx
src/components/admin/CreateProjectFromPost.tsx
src/globals/Design/fields/tenant-fields.tsx
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:
// File: payload.config.ts
export default buildConfig({
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:
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:
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.
Thanks, Matija