CLOUDFLARE has rebuilt the Node[.]js compatibility story for its Workers runtime by overhauling the module registry inside workerd, the core open‑source component of Workers. The aim is to make module loading faster, more standards‑compliant, and better aligned with Node[.]js expectations while retaining compatibility with existing Workers deployments.
Alongside broader Node[.]js API support now enabled by default, the company has increased the practical size limits for Worker bundles and emphasised that API compatibility alone is not enough; module resolution, loading, and caching behaviour must also match Node’s patterns.
The new module registry treats specifiers as URLs, enabling features such as import.meta[.]url, import.meta[.]main, and import.meta[.]resolve(), and supports query strings and fragments as distinct module identities. It also validates import attributes (for example, import data from './config[.]json' with { type: 'json' }) and adheres to Node[.]js require(esm) rules when loading ES modules via require().
WebAssembly modules can be imported via source phase imports, returning a WebAssembly[.]Module directly rather than a compiled wrapper. The registry performs lazy compilation and shareable caching per V8 isolate, improving efficiency across multiple replicas. Developers can opt in with the new_module_registry compatibility flag, though Cloudflare notes there is no automatic enablement yet based on compatibility dates. The article invites feedback and points to detailed workerd reference documentation for deeper technical guidance.