Parlons de votre projet
Architecture web

Workers et Node.js : tester le nouveau registre de modules avant migration

Cloudflare ouvre l’accès à un nouveau registre de modules pour Workers. Isolez ce que le bundler transforme, ce que le moteur résout et les comportements exigés par vos dépendances.

Nouveau registre de modules Cloudflare Workers.

Cloudflare ouvre l’accès à un nouveau registre de modules pour Workers. Avant d’en déduire que votre application Node.js peut migrer sans adaptation, il faut identifier ce que le bundler transforme, ce que le moteur résout et quels comportements vos dépendances exigent réellement.

Ce que change le nouveau registre

Cloudflare a annoncé le 9 septembre 2026 un registre de modules Workers reconstruit, accessible avec l’indicateur de configuration explicite new_module_registry. La publication décrit notamment import.meta.url, import.meta.main, import.meta.resolve(), les spécificateurs URL, require(esm) et la compilation différée ; l’implémentation précédente reste disponible. Ces capacités sont celles annoncées par Cloudflare, pas une preuve de compatibilité générale avec Node.js. [source Cloudflare]

L’indicateur doit être ajouté à la liste de compatibilité existante, sans la remplacer. Une configuration de test peut ajouter new_module_registry à la liste déjà présente ; elle ne constitue pas une commande de déploiement.

{ "compatibility_flags": ["new_module_registry"] }

Cet extrait montre seulement l’indicateur à ajouter. Il ne remplace pas le fichier de configuration complet ni les indicateurs déjà présents.

Séparer le bundler du moteur d’exécution

Le bundler, outil qui assemble les fichiers de code, peut supprimer, transformer ou regrouper une importation avant son arrivée au moteur d’exécution (runtime). Un import visible dans le source ne prouve donc pas que le registre le résoudra. Inspectez l’artefact produit et relevez le mode de construction, les versions et les options avant de conclure à un changement de runtime. Cette séparation complète notre article sur la chaîne de construction.

Le bundler transforme un artefact avant que le runtime Workers résolve les modules.
La construction et la résolution à l’exécution sont deux couches distinctes.

Construire des cas de test limités et observables

Préparez un petit exemple isolé, ou fixture, par mécanisme : URL de module avec paramètres et fragment, import.meta.resolve(), import dynamique, frontière entre les modules JavaScript ESM et CommonJS (deux formats de chargement) et erreur de chargement. La documentation workerd décrit la conception du registre ; pour reproduire un test, épinglez la référence a42a33b0d43d80b9554d3f9d7f04c153d6b0c45f au lieu d’utiliser une branche mouvante. [référence workerd figée]

Les exemples ci-dessous et leurs fichiers documentaires sont une proposition de test ; ils n’ont pas été exécutés dans Workers. Elles ne donnent aucun résultat attendu fabriqué. Un échec doit être inspecté : il peut venir d’une dépendance, de la construction, du format ESM/CommonJS ou de l’environnement, et pas seulement du registre.

// 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"); }

Le protocole doit relever l’URL, le rôle de point d’entrée, l’identité des instances et la classe d’erreur. Conservez aussi un cas de module absent et un cas de chargement CommonJS d’un module ESM. Une vérification de syntaxe seule ne valide aucun de ces comportements dans Workers.

DépendanceMécanismeCas testéConstatIncertitudeDécision
À renseignerÀ identifierNon exécutéNon mesuréÀ qualifierÀ décider

Comparer sans confondre runtime et dépendances

Utilisez le même artefact, les mêmes dépendances et les mêmes entrées dans deux configurations documentées : registre précédent et activation de test. Conservez journaux, assertions et éventuelles transformations du bundle. Cette comparaison ne promet aucun gain de vitesse ni une migration automatique ; elle isole simplement la variable étudiée.

Qualification d’un même artefact avec l’ancien registre et avec le nouveau registre de modules Workers.
La décision repose sur des constats par dépendance, pas sur une promesse universelle.

Préparez aussi le retour arrière dans l’environnement de test : retirez seulement le indicateur ajouté, conservez les autres indicateurs et notez les critères qui justifieraient de poursuivre ou d’arrêter. La compatibilité Workers se démontre par application, dépendance et comportement utilisé.

Partager cet article