Cloudflare Workers elimina el límite de tamaño de bundle y llega a 64 MiB

Imagen: Cloudflare

Cloudflare ha reescrito el registro de módulos de Workers, el componente de workerd —el runtime de código abierto que sostiene la plataforma— encargado de resolver, cargar y cachear el código de cada aplicación. Según cuenta Cloudflare, el objetivo es que Workers se comporte más como Node.js a la hora de manejar módulos ESM, CommonJS y WebAssembly, y no solo a la hora de exponer sus APIs.

El cambio es opcional y se activa con el flag de compatibilidad new_module_registry. No tiene fecha de activación por defecto, así que ningún Worker, viejo o nuevo, lo adopta automáticamente por su fecha de compatibilidad: hay que añadirlo a mano, y el registro anterior sigue funcionando igual para quien no lo toque.

---

Por qué el registro antiguo se quedaba corto

El registro original resolvía los especificadores de importación como rutas de sistema de archivos, no como URL. Eso impedía cosas concretas: no había forma limpia de implementar import.meta.url, los imports relativos no seguían las mismas reglas que new URL(), y protocolos como node: o cloudflare: se trataban como prefijos de cadena especiales en lugar de protocolos de verdad. Además, compilaba todo el bundle del Worker por adelantado, se usara o no cada módulo, y guardaba una copia privada por cada réplica de isolate de V8, lo que en la práctica suponía compilar el mismo código varias veces.

El nuevo registro parte de las URL como formato de especificador desde el diseño, y trata la carga perezosa y el reparto de caché como algo pensado desde el principio.

---

Aplicaciones Node.js más grandes y sin el límite de bundle comprimido

El anuncio no es solo técnico para quien mira el registro de módulos por dentro. Cloudflare confirma que Workers ya soporta por defecto todas las APIs estables de Node.js útiles en un contexto serverless, y que ha eliminado el límite de tamaño de bundle comprimido, permitiendo desplegar aplicaciones Node.js de hasta 64 MiB en todos los planes. Con el nuevo registro, los módulos de las APIs de Node.js no se empaquetan como polyfill dentro del código, sino que se importan como módulos ya integrados en workerd, igual que los módulos Wasm, de texto o binarios, que se referencian por especificador en lugar de inlinearse.

---

Import.meta, require(esm) y errores más predecibles

El nuevo registro añade soporte a import.meta.main —verdadero solo en el módulo configurado como punto de entrada del Worker— y a import.meta.resolve(), que ahora funciona como una transformación de cadena pura, igual que en Node.js y en los navegadores. Los imports relativos se resuelven como lo haría new URL(specifier, base), y una consecuencia directa es que una misma ruta con distinta cadena de consulta o fragmento se trata como una instancia de módulo genuinamente distinta, con su propio import.meta.url y su propio estado.

También cambia la validación de atributos de importación: el tipo json está habilitado, text y bytes se reconocen pero se rechazan con un error específico, y cualquier clave que no sea type ahora falla en lugar de ignorarse en silencio, algo que el registro anterior hacía en contra de la especificación. El comportamiento de require() sobre un módulo ES sigue las reglas de Node.js, incluida la restricción de que lanza un error si el módulo, o cualquier parte de su grafo, tiene un await de nivel superior, en lugar de bloquear o devolver algo a medio terminar. Y los errores de resolución quedan unificados: un módulo no encontrado es un Error plano, un especificador que no se puede interpretar como URL es un TypeError, y una dependencia circular que V8 no puede resolver es un Error plano, nunca un TypeError.

---

Qué significa esto para quien despliega en Workers hoy

Nada de esto obliga a nadie a moverse: si tu Worker ya funciona y no lo tocas, sigue con el registro antiguo tal cual, porque Cloudflare mantiene ambas implementaciones en paralelo y el flag no se activa solo. Donde sí cambia algo concreto es para quien choca con el límite de tamaño de bundle: si tu aplicación Node.js se ha quedado corta de espacio o dependías de trucos de empaquetado para entrar en el límite anterior, el nuevo tope de 64 MiB en todos los planes es la variable que hay que revisar antes de nada. Para quien construye herramientas encima de import() —un loader propio, un wrapper con reintentos—, la unificación de las clases de error permite dejar de adivinar por el texto del mensaje y distinguir por la clase de error.

La compañía pide feedback explícitamente y remite cualquier comportamiento que parezca una regresión al repositorio de workerd, de código abierto, donde también ha publicado la documentación técnica de cómo interactúa el nuevo registro con las APIs de módulos de V8. Para quien quiera probarlo sin comprometer producción, la vía razonable es activar el flag en un entorno de pruebas primero, ya que no hay fecha de activación automática y las aplicaciones existentes no se ven afectadas hasta que alguien lo pida expresamente.

Te puede interesar

Tech Planet participa en el programa de afiliados de Amazon. Si compras a través de estos enlaces, recibimos una pequeña comisión sin coste extra para ti, lo que nos ayuda a seguir creando contenido como este.