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

Cloudflare Workers can now deploy Node.js applications up to 64 MiB with zero limits on compressed bundle size, all while dropping the requirement to collapse your code into a single monolithic file. 👇

Historically, Workers tooling bundled an entire application into one massive JavaScript file. The underlying runtime, `workerd`, treated imports as filesystem paths rather than standard URLs. This broke web and Node.js primitives like `import.meta.url`, `import.meta.resolve()`, and specifier query parameters. It also forced `workerd` to compile every module up front and duplicate that compiled code across every V8 isolate replica.

Cloudflare completely rebuilt the `workerd` module registry around standard URL resolution, lazy compilation, and shared module caching.

The new registry treats every specifier as a URL under the hood. Importing `./counter.js?a` and `./counter.js?b` now creates two distinct module instances with separate top-level state, matching browser spec compliance.

Import attributes are strictly validated. Passing an unknown attribute key or a mismatched type now throws an exception rather than silently disappearing.

When calling `require()` on an ES module, the runtime follows Node.js' exact `require(esm)` rules. It returns the module's `module.exports` string export or its namespace object. If the target module contains a top-level `await`, `require()` immediately throws an error because synchronous imports cannot wait for asynchronous evaluation.

Modules now compile lazily upon their first import rather than during initial runtime startup. Cloudflare also added support for WebAssembly source phase imports, allowing developers to import raw `WebAssembly.Module` objects directly using `import source`.

The rewrite gives Workers full Node.js module resolution parity, predictable error classes across all import paths, and allows bundlers like Rolldown to emit clean, multi-module graphs. You can test the new engine today by enabling the `new_module_registry` compatibility flag.