How we rebuilt Cloudflare Workers’ module registry for Node.js compatibility

We’ve rewritten the module registry in workerd, the core open-source component of the Workers runtime, to be faster, more standards-compliant, and more closely aligned with Node.js' module registry.

Over the past few years, we’ve been adding support for more and more Node.js runtime APIs. The Workers runtime now supports every stable API from Node.js that you might want to use in a serverless context, and these APIs are now enabled by default, letting you deploy even larger Node.js apps to Cloudflare (now up to 64 MiB on all plans — we’ve removed the limit on compressed bundle size).

But API compatibility alone is not enough: Node.js applications also depend on how the runtime resolves, loads, and caches modules. ESM, CommonJS, and WebAssembly are each types of modules that you can import in your Worker’s code. The system within the runtime that handles all of this is called the module registry.

You can start using it today by enabling the new_module_registry compatibility flag in your Worker.

When you enable the new_module_registry compatibility flag:

• import.meta.url, import.meta.main, and import.meta.resolve() all work.
• Module specifiers are parsed and resolved as real URLs, including query strings and fragments.
• node: built-ins resolve to the same module instance no matter how you reach them.
• Import attributes (with { type: 'json' }) are correctly validated.
• require() on an ES module follows Node.js' require(esm) rules.
• Errors use consistent classes and messages regardless of which loading path triggered them.
• Modules compile lazily when first imported (statically or dynamically).
• WebAssembly modules support source phase imports.