---
title: "Fix Turbopack React Client Manifest Errors with Payload CMS Admin Import Maps"
slug: "payload-turbopack-react-client-manifest-error-debugging"
published: "2025-10-07"
updated: "2025-12-25"
categories:
  - "Payload"
tags:
  - "Payload CMS"
  - "Turbopack"
  - "React Client Manifest"
  - "Next.js 15"
  - "admin import map"
  - "webpack fallback"
  - "RSC"
  - "debugging"
llm-intent: "reference"
audience-level: "intermediate"
framework-versions:
  - "next.js@15.5.4"
  - "payload@3.57.0"
  - "turbopack@next"
  - "webpack@5"
status: "stable"
llm-purpose: "Guide to fixing React Client Manifest errors caused by Payload CMS admin import maps when using Next.js Turbopack."
llm-prereqs:
  - "Access to Next.js"
  - "Access to Payload CMS"
  - "Access to Turbopack"
  - "Access to Webpack"
  - "Access to TypeScript"
llm-outputs:
  - "Completed outcome: Guide to fixing React Client Manifest errors caused by Payload CMS admin import maps when using Next.js Turbopack."
---

**Summary Triples**
- (Payload admin import map, can contain, static imports of `use client` admin components)
- (Turbopack, resolves, admin import map client imports into the React Client Manifest, causing missing-module errors)
- (Classic webpack dev server, behavior, does not include admin-only import-map client imports in RSC manifest and therefore does not loop)
- (Immediate mitigation, is, start dev without Turbopack (`pnpm dev --no-turbo`))
- (Reliable long-term fix (practical), options, move import map out of app routes, use dynamic/runtime imports, or await Turbopack fix)

### {GOAL}
Guide to fixing React Client Manifest errors caused by Payload CMS admin import maps when using Next.js Turbopack.

### {PREREQS}
- Access to Next.js
- Access to Payload CMS
- Access to Turbopack
- Access to Webpack
- Access to TypeScript

### {STEPS}
1. Follow the detailed walkthrough in the article content below.

<!-- llm:goal="Guide to fixing React Client Manifest errors caused by Payload CMS admin import maps when using Next.js Turbopack." -->
<!-- llm:prereq="Access to Next.js" -->
<!-- llm:prereq="Access to Payload CMS" -->
<!-- llm:prereq="Access to Turbopack" -->
<!-- llm:prereq="Access to Webpack" -->
<!-- llm:prereq="Access to TypeScript" -->
<!-- llm:output="Completed outcome: Guide to fixing React Client Manifest errors caused by Payload CMS admin import maps when using Next.js Turbopack." -->

# Fix Turbopack React Client Manifest Errors with Payload CMS Admin Import Maps
> Guide to fixing React Client Manifest errors caused by Payload CMS admin import maps when using Next.js Turbopack.
Matija Žiberna · 2025-10-07

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.

   ```bash
   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:

   ```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:

- `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:

```ts
// 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:

```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:

```
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

## LLM Response Snippet
```json
{
  "goal": "Guide to fixing React Client Manifest errors caused by Payload CMS admin import maps when using Next.js Turbopack.",
  "responses": [
    {
      "question": "What does the article \"Fix Turbopack React Client Manifest Errors with Payload CMS Admin Import Maps\" cover?",
      "answer": "Guide to fixing React Client Manifest errors caused by Payload CMS admin import maps when using Next.js Turbopack."
    }
  ]
}
```