Cloudflare Workers Rewrites Module Registry to Enhance Node.js Compatibility

The workerd runtime of Cloudflare Workers has rewritten its module registry to achieve precise compatibility with Node.js and improve speed. With this change, all stable Node.js APIs are supported by default in serverless contexts, and the compressed bundle size limit has been removed, allowing deployments of up to 64 MiB on all plans.

Limitations of the Previous Approach and the New Design

The previous runtime adopted a method of bundling dependencies into a single file using tools like esbuild due to a lack of consistency in module resolution. This was intended to avoid standard compatibility issues such as the lack of support for import.meta.resolve(), but it resulted in inefficiencies, including duplicate source compilation and memory waste for each V8 isolate.

The new registry adopts URL as the specifier format and incorporates lazy compile and cache sharing into its initial design. This allows modern bundlers like Rolldown to reduce transformations and rely more on the runtime's module resolution capabilities.

Features Supported by the new_module_registry Flag

Enabling the new_module_registry compatibility flag applies the following improvements:

• import.meta support: import.meta.url, import.meta.main, and import.meta.resolve() behave identically to Node.js and browser standards.
• URL-based resolution: Module specifiers are resolved as actual URLs, including query strings and fragments, adhering to percent-encoding normalization rules.
• Import attributes validation: Exceptions are thrown when using unrecognized attributes such as with { type: 'json' }, preventing specification violations.
• require(esm) rule compliance: When requiring ES modules from CommonJS, Node.js rules are followed, and modules containing top-level await are blocked from being required.
• WebAssembly support: Compiled WebAssembly.Module instances can be imported directly via source phase imports.

Adoption and Caveats

The new registry operates in parallel with the existing registry, and deployed Workers continue to function using the previous method. To use the new features, the new_module_registry flag must be explicitly added, and a default enablement date has not yet been set. node: built-ins are treated as built-in modules rather than polyfills and resolve to the same instance regardless of the access path.