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

·Matija Žiberna·
Fix Turbopack React Client Manifest Errors with Payload CMS Admin Import Maps

📚 Comprehensive Payload CMS Guides

Detailed Payload guides with field configuration examples, custom components, and workflow optimization tips to speed up your CMS development process.

No spam. Unsubscribe anytime.

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

  1. Start the project with Turbopack.

    pnpm dev --turbo
    
  2. Navigate to any frontend route handled by src/app/(frontend)/[...slug]/page.tsx (for example /home).

  3. 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.

  4. 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

0

Comments

Leave a Comment

Your email will not be published

10-2000 characters

• Comments are automatically approved and will appear immediately

• Your name and email will be saved for future comments

• Be respectful and constructive in your feedback

• No spam, self-promotion, or off-topic content

Matija Žiberna
Matija Žiberna
Full-stack developer, co-founder

I'm Matija Žiberna, a self-taught full-stack developer and co-founder passionate about building products, writing clean code, and figuring out how to turn ideas into businesses. I write about web development with Next.js, lessons from entrepreneurship, and the journey of learning by doing. My goal is to provide value through code—whether it's through tools, content, or real-world software.

You might be interested in