El ChunkLoadError de Turbopack + Cloudflare y cómo evitarlo

Turbopack es rápido — dev server casi instantáneo, rebuilds en milisegundos. La tentación de usarlo también para el build de producción es lógica. Pero al desplegar un proyecto con @opennextjs/cloudflare y Turbopack activo en el build de producción, el resultado fue un ChunkLoadError en producción real, no solo en local.

Qué está pasando

El adaptador de Cloudflare todavía asume ciertos patrones de generación de chunks que corresponden al compilador clásico de Webpack. Turbopack organiza y nombra los chunks de forma distinta, y esa diferencia rompe la resolución de módulos en el runtime de Cloudflare Workers en el momento de servir la página, no en el momento de compilar.

Cómo lo detecté

Local con wrangler dev no lo mostraba de forma consistente — el error solo aparecía tras un despliegue real a Cloudflare, lo que lo convierte en un bug particularmente molesto: pasa los checks locales y falla en producción con usuarios reales viendo una página rota.

La solución que aplico hoy

Forzar el build de producción para Cloudflare con el compilador clásico (next build sin el flag de Turbopack), reservando Turbopack únicamente para next dev. El script build:cf del proyecto usa explícitamente el compilador estable hasta que las notas de la próxima versión de @opennextjs/cloudflare confirmen soporte de Turbopack en producción.

La lección de fondo

Cuando una herramienta nueva y una integración de despliegue todavía no se han probado juntas a fondo, la señal más fiable no es que compile en local — es un despliegue real. Antes de dar por bueno un cambio de tooling en cualquier proyecto de cliente, lo verifico con un despliegue de verdad, no solo con el build local.