How we rebuilt Cloudflare Workers’ module registry for Node.js compatibility
- ID
- 22778
- Status
- summarized
- Published
- 09 Sep 2026, 9:00 PM
- Fetched
- 09 Sep 2026, 10:58 PM
- Provider
- Cloudflare Blog
- Category
- infrastructure
- Original URL
- https://blog.cloudflare.com/workers-module-registry-nodejs/
- Source URL
- https://blog.cloudflare.com/rss/
Summary
- Score
- 6.5
- Created
- 09 Sep 2026, 10:59 PM
- Tags
- Audience
- developersvibe_coders
What happened
Cloudflare rewrote the module registry in workerd (the Workers runtime) to better match Node.js module resolution, caching, and loading semantics. The new registry is opt-in via the new_module_registry compatibility flag and brings support for import.meta.url, import.meta.resolve(), real URL-based specifier parsing, node: built-in singleton resolution, import attributes, require(esm) rules, lazy compilation, and WebAssembly source phase imports. Cloudflare also raised the Worker size limit to 64 MiB on all plans and removed the compressed bundle size limit.
Why it matters
If you deploy Node.js-heavy apps to Cloudflare Workers, enabling the new_module_registry flag will fix subtle module resolution mismatches (import.meta.url, node: singleton behavior, import attributes) that previously broke ports of existing Node code. The 64 MiB limit and removed compressed bundle cap mean you can now ship significantly larger Node.js apps without restructuring.
Discussion angle
Whether to flip new_module_registry on existing Workers now or wait — the flag changes module resolution semantics, so it could fix some imports while breaking others that relied on the old behavior.