Cloudflare is opening access to a new module registry for Workers. Before inferring that your Node.js application can migrate without adaptation, identify what the bundler transforms, what the engine resolves, and which behaviours your dependencies actually require.
What the new registry changes
On 9 September 2026, Cloudflare announced a rebuilt Workers module registry, available with the explicit configuration flag new_module_registry. The publication describes, in particular, import.meta.url, import.meta.main, import.meta.resolve(), URL specifiers, require(esm) and deferred compilation; the previous implementation remains available. These are capabilities announced by Cloudflare, not proof of general compatibility with Node.js. [Cloudflare source]
The flag must be added to the existing compatibility list, without replacing it. A test configuration can add new_module_registry to the list already present; it is not a deployment command.
{ "compatibility_flags": ["new_module_registry"] }This excerpt only shows the flag to add. It does not replace the complete configuration file or existing flags.
Separating the bundler from the runtime
The bundler, the tool that assembles source files, can remove, transform or bundle an import before it reaches the runtime engine. An import visible in source therefore does not prove that the registry will resolve it. Inspect the generated artifact and record the build mode, versions and options before concluding that the runtime has changed. This distinction complements our article on the build chain.
Building bounded, observable test cases
Prepare one small isolated example, or fixture, for each mechanism: a module URL with parameters and fragment, import.meta.resolve(), dynamic import, the boundary between ESM and CommonJS JavaScript modules (two loading formats), and a loading error. The workerd documentation describes the registry design; to reproduce a test, pin reference a42a33b0d43d80b9554d3f9d7f04c153d6b0c45f instead of using a moving branch. [pinned workerd reference]
The examples below and their documentation files are a proposed test; they have not been run in Workers. They provide no fabricated expected result. A failure must be inspected: it may come from a dependency, the build, the ESM/CommonJS format or the environment, and not only from the registry.
// url-meta.mjs — exemple documentaire non exécuté dans Workers
export const currentUrl = import.meta.url;
export const isMain = import.meta.main;
export const resolved = import.meta.resolve("./url-meta.mjs?mode=test#fixture");
// Comparer séparément les identités et les erreurs avec chaque registre.
export async function loadVariant() {
return import("./url-meta.mjs?mode=dynamic#fixture");
}
The protocol must record the URL, entry-point role, instance identity and error class. Also retain a missing-module case and a CommonJS loading case for an ESM module. A syntax check alone validates none of these behaviours in Workers.
| Dependency | Mechanism | Case tested | Observation | Uncertainty | Decision |
|---|---|---|---|---|---|
| To be completed | To be identified | Not run | Not measured | To be qualified | To be decided |
Comparing without confusing the runtime and dependencies
Use the same artifact, dependencies and inputs in two documented configurations: the previous registry and the test activation. Retain logs, assertions and any bundle transformations. This comparison promises neither a speed gain nor an automatic migration; it simply isolates the variable studied.
Also prepare the rollback in the test environment: remove only the added flag, keep the other flags and note the criteria that would justify continuing or stopping. Workers compatibility is demonstrated by application, dependency and behaviour used.