How we rebuilt Cloudflare Workers’ module registry for Node.js compatibility
- Source
- blog.cloudflare.com
- Date
Cloudflare rebuilt workerd's module registry from scratch so ESM, CommonJS, and WebAssembly module resolution match Node.js semantics directly, rather than approximating them. The rewrite gives every module a single shared instance of Node's built-in modules, makes import.meta.resolve() work correctly, validates import attributes, and matches Node's exact behavior for require() calls against ESM modules. Cloudflare says these are the specific gaps that caused Node.js applications ported to Workers to hit module-resolution bugs that only surfaced at runtime, since the prior implementation approximated Node's behavior rather than replicating it. The new resolution logic sits behind a compatibility flag, alongside a newly uniform 64 MiB bundle limit applied across all Workers plans. For teams running existing Node.js codebases on Workers, enabling the flag removes a specific, previously hard-to-diagnose class of failures without requiring changes to application code.

Context
Cloudflare's Workers update addresses a compatibility problem beyond having the right Node.js functions: applications also depend on how imported code is found and loaded. Its rewritten module registry resolves imports as URLs and supports module-location operations that the previous registry lacked. This removes specific reasons a dependency could fail despite its required APIs being available. Engineering account.
The registry also compiles modules when they are first imported instead of compiling the entire bundle upfront. At the announcement, developers had to enable the new_module_registry compatibility flag explicitly. Existing Workers retained the old behavior unless opted in.
“The original registry resolves specifiers as filesystem-style paths, not URLs.”
“None of this is really a bug, but it made it difficult to evolve the implementation without breaking changes.”
Checking sign-in…
Loading comments…

