AI & Agent Dev Bug Sandbox Back to Radar

Turbopack Dev: Computed Next/Dynamic RSC Loaders With Client Descendants Fail Under CacheComponents

In Next.js 16.3.0 and 16.3.1-canary.1, enabling `cacheComponents` in Turbopack dev causes a module factory error for client reference proxies when using computed `next/dynamic` loaders that render Server Components with Client Component descendants. The error occurs after HMR, while full page reload does not trigger it.

mediumConfidence 70%Next.js Affected V16.3.0 Affected V16.3.1-Canary.1

Origin Analysis

Turbopack's `cacheComponents` optimization caches client reference proxy modules without retaining their associated module factories, and HMR invalidation of computed `next/dynamic` RSC modules does not re-evaluate these proxies, leading to the `module factory is not available` error.

1. Clone the reproduction repository: https://github.com/dl-web-dev/next-dynamic-rsc-factory-repro.git 2. Run `npm install`. 3. Run `npm run dev`. 4. Open http://localhost:3000/demo and observe the module factory error in the server console after HMR (e.g., editing a file that triggers reload of the dynamic import). 5. Note that a full hard reload of the page does not produce the error.

Fixing Code Block

// next.config.js
const nextConfig = {
  experimental: {
    cacheComponents: false,
  },
};

module.exports = nextConfig;

Disabling `cacheComponents` avoids the Turbopack module caching path that evicts client reference proxy factories. This is a temporary hotfix that restores correct dev-time HMR behavior until the underlying cache invalidation bug is fixed upstream.

Edge Case Audit

Disabling `cacheComponents` may reduce build/development performance or disable the intended caching optimization. This hotfix should be reverted once a proper fix is released. Always test in a staging environment before applying to production, and ensure rollback is possible by simply removing the experimental flag.