Cloudflare hat am 9. September 2026 den Modul-Loader von workerd neu aufgebaut. workerd ist die Open-Source-Runtime hinter Cloudflare Workers. Der Umbau betrifft einen Teil der Plattform, an dem Node.js-Kompatibilität häufig entscheidet: die Auflösung, Identität, Kompilierung und Zwischenspeicherung von Modulen.
Cloudflare Workers unterstützt nach eigener Angabe inzwischen die stabilen Node.js-APIs, die in einem Serverless-Kontext sinnvoll sind, und aktiviert Node.js-Kompatibilität standardmäßig. Ein Paket kann trotzdem scheitern, wenn ESM und CommonJS anders zusammenspielen oder Modul-Specifier anders interpretiert werden als unter Node.js.
Modul-Specifier werden als URLs behandelt
Die bisherige Registry behandelte Modul-Specifier intern stärker wie Dateisystempfade. Die neue Implementierung verwendet URLs als Grundlage der Modulidentität.
Damit funktionieren unter anderem import.meta.url, import.meta.main und import.meta.resolve(). Relative Imports folgen denselben URL-Regeln wie new URL(specifier, base). Query-Strings und Fragmente gehören zur Modulidentität: ./counter.js?a und ./counter.js?b können getrennte Modulinstanzen sein, obwohl sie auf dieselbe Quelldatei zeigen.
Diese Semantik betrifft Bibliotheken und Build-Tools direkt. Eine Runtime kann viele Node-APIs anbieten und trotzdem inkompatibel bleiben, wenn ihr Modulmodell andere Regeln verwendet.
require() und ESM folgen stärker Node.js
Wenn require() ein ES-Modul lädt, folgt workerd nun den require(esm)-Regeln von Node.js. Enthält der Modulgraph Top-Level-Await, kann require() kein synchron fertiges Ergebnis liefern und wirft einen Fehler. Für solche Fälle bleibt import() der passende asynchrone Weg.
Import Attributes werden ebenfalls strenger geprüft. Cloudflare nennt JSON derzeit als unterstützten Typ. Unbekannte Attribute werden nicht mehr still ignoriert, sondern führen zu einem Fehler. Für Bibliotheken ist das relevant, weil Code auf Workers damit weniger von dem Verhalten abweicht, das Node.js und die zugrunde liegenden Standards vorgeben.
Module werden erst bei Bedarf kompiliert
Der alte Loader kompilierte laut Cloudflare den gesamten Worker-Bundle im Voraus und hielt pro V8-Isolate eine eigene Kopie. Die neue Registry kompiliert Module erst bei ihrer ersten Verwendung. Zusätzlich können kompilierte Daten zwischen Isolates geteilt werden.
Cloudflare beschreibt dadurch weniger redundante Kompilierung und geringeren Speicherbedarf. Der veröffentlichte Beitrag nennt allerdings keine Messwerte für Startzeit, CPU-Zeit oder Arbeitsspeicher. Wie groß der Effekt bei typischen Workers ausfällt, lässt sich aus den bisher veröffentlichten Daten deshalb nicht beziffern.
Bundler könnten weniger Kompatibilitätsarbeit übernehmen
Wrangler, esbuild, Vite oder Rolldown lösen heute bereits viele Unterschiede vor dem Deployment. Sie verarbeiten Imports, wandeln CommonJS bei Bedarf in ESM um und erzeugen einen Modulgraphen für die Zielruntime.
Wenn workerd selbst näher an Node.js- und Web-Modulsemantik arbeitet, können Toolchains einen Teil dieser Übersetzung künftig weglassen. Cloudflare beschreibt das als mögliche Folge der neuen Architektur, nicht als bereits vollzogene Änderung aller Bundler.
Der Loader unterstützt außerdem WebAssembly Source Phase Imports. Dabei kann Code ein kompiliertes WebAssembly.Module importieren, ohne es sofort zu instanziieren. workerd implementiert damit eine neue Sprachfunktion direkt im Modulmodell.
Die neue Registry bleibt vorerst opt-in
Bestehende Worker wechseln nicht automatisch. Entwickler müssen aktuell den Compatibility Flag newmoduleregistry aktivieren. Cloudflare hat noch kein Datum genannt, an dem die Registry über ein Compatibility Date zum Standard wird.
Das reduziert das Risiko stiller Verhaltensänderungen. Ein bestehender Worker kann beispielsweise von einer bisher tolerierten Auflösung oder einem ignorierten Import-Attribut abhängen. Solche Unterschiede sind schwerer zu erkennen als eine fehlende API, weil der Code häufig erst in einer bestimmten Importkombination abweicht.
Parallel hat Cloudflare das Größenlimit für Worker-Bundles auf 64 MiB unkomprimiert für Free- und Paid-Pläne angehoben. Zuvor wurden Deployments oberhalb von 3 MB komprimiert im Free- und 10 MB im Paid-Plan abgelehnt. Das alte komprimierte Limit ist entfallen; maßgeblich sind nun 64 MiB unkomprimiert.
Für größere Node.js-Anwendungen lösen die beiden Änderungen unterschiedliche Probleme. Das höhere Limit schafft Platz für umfangreichere Abhängigkeiten. Der neue Modul-Loader soll dafür sorgen, dass deren Import- und Laufzeitverhalten näher an Node.js liegt.
Quavon arbeitet bei Webanwendungen stark mit dem Node.js- und Next.js-Ökosystem. Bei einer Edge-Runtime ist deshalb nicht nur die Liste unterstützter APIs relevant. Entscheidend ist auch, ob npm-Pakete dieselben Erwartungen an ESM, CommonJS, import.meta und Modulidentität erfüllt bekommen.
Cloudflare hat diesen Teil der Runtime jetzt neu implementiert. Ob dadurch im Alltag messbar weniger Bundling-Sonderfälle und schnellere Starts entstehen, ist noch offen; dafür fehlen bislang veröffentlichte Messdaten.
Quellen: https://blog.cloudflare.com/workers-module-registry-nodejs/ https://developers.cloudflare.com/changelog/post/2026-09-04-increased-worker-size-limit/