État de prise en charge actuel des modules ECMAScript (ESM) dans Node.js:
- La prise en charge expérimentale d'ESM a été ajoutée dans Node.js 8.5.0 le 12 septembre 2017.
- Après cela, le comité de pilotage technique de Node.js a formé l'équipe responsable de l' équipe des modules pour aider à concevoir les pièces manquantes pour la prochaine version (non expérimentale). Cette équipe est composée de personnes issues de diverses industries de développement Web (frontend, backend, moteurs JS, etc.).
En octobre, l'équipe Modules a publié le "Plan de mise en œuvre des nouveaux modules" . Ce message explique ce qu'il contient.
Phases
Le processus est divisé en trois phases:
- Phase 1: créer un noyau «minimum» - l'ensemble de règles et de capacités de base, aussi minimal et certain que possible.
- À partir de la phase 2: création de fonctionnalités plus complexes basées sur le noyau.
Un noyau minimal sera la base des travaux futurs. La nouvelle conception remplacera également l'implémentation expérimentale actuelle dès qu'elle aura acquis des capacités similaires.
Phase 1: prise en charge minimale du noyau ESM dans Node.js
Simplification des identifiants de module
L'un des objectifs de Modules Team est d'atteindre «l'équivalence du navigateur» : Node.js doit être aussi proche que possible des navigateurs. Le noyau y parvient en simplifiant l'analyse des identifiants de module (URL pointant vers des modules):
- Chaque identifiant de module doit se terminer par un nom de fichier avec l'extension. C’est
- Les extensions ne sont pas ajoutées automatiquement
- L'importation de répertoires n'est pas prise en charge (soit par redirection vers
dir/index.mjs , soit par lecture du champ main dans package.json ).
- Les modules ES peuvent importer des modules Node.js intégrés (
path , etc.). Ils sont la seule exception à la règle précédente. - Par défaut, seuls les fichiers avec l'extension
.mjs sont .mjs (voir Phase 2 si vous êtes intéressé par le statut des autres extensions). Ainsi, d'autres types de modules ne peuvent pas être importés par import : modules CommonJS, fichiers JSON, modules natifs.
Intégration des fonctionnalités essentielles de CommonJS aux modules ES
- URL du module actuel (similaire à
__filename de CommonJS): import.meta.url - Importer dynamiquement des modules ES (disponibles via
require() dans CommonJS): import()
La compatibilité
- Les modules ES pourront importer des modules CommonJS via
createRequireFromPath() . Cela fonctionnera comme suit (il est prévu de créer une méthode abrégée, par exemple, la fonction createRequireFromUrl() ):
import {createRequireFromPath as createRequire} from 'module'; import {fileURLToPath as fromPath} from 'url'; const require = createRequire(fromPath(import.meta.url)); const cjsModule = require('./cjs-module.js');
- Les modules CommonJS pourront charger les modules ES via
import() .
Phase 2 et plans futurs
- Dans la deuxième phase, nous attendons:
- Prise en charge des identifiants «nus» tels que
'lodash' . Très probablement, cela inclura un moyen de mapper ces identifiants sur des chemins réels. - Prise en charge d'autres extensions de fichiers en plus de
.mjs . Cela inclut, entre autres, la prise en charge des modules ES dans les fichiers .js .
- La phase 3 est susceptible de se concentrer sur les chargeurs de modules avec des points d'extension où les utilisateurs peuvent brancher leur logique.
Quand puis-je utiliser des modules ES dans Node.js?
- Derrière le drapeau: disponible dès maintenant
- Attention: le comportement ne correspond pas encore à celui décrit ci-dessus en phase 1 (à partir de Node.js 11.5.0)
- Sans drapeau et conformément à la phase 1: l'équipe Modules essaie de rendre cela possible dès que possible. Nous espérons que les modules seront libérés du drapeau dans Node.js 14 (avril 2020) et portés aux versions précédentes, si possible.
Foire aux questions
- Pourquoi ai-je besoin d'une nouvelle
.mjs fichier .mjs ?
- Chaque décision de faire la distinction entre les formats ESM et CommonJS a ses avantages et ses inconvénients. L'utilisation d'une résolution distincte semble être une bonne option ( plus d'informations ).
- Pourquoi Node.js devrait-il se comporter comme un navigateur?
- Parce que cela rend possible la réutilisation du code. Par exemple, pour créer des bibliothèques qui fonctionnent à la fois dans les navigateurs et dans Node.js
- Cela devrait également faciliter la commutation entre le backend et le frontend pendant le codage.
- Pourquoi toutes ces restrictions de compatibilité?
- Il existe des différences assez fortes entre les modules ES et CommonJS dans la structure (statique contre dynamique) et la méthode de chargement (asynchrone contre synchrone). Les contraintes aident à garder les choses simples - étant donné qu'à long terme, la grande majorité seront des modules ES.
- Pourquoi tout cela dure-t-il si longtemps?
- De nombreuses parties prenantes sont impliquées ici et de nombreuses plates-formes différentes sont impliquées (Node.js, npm, navigateurs, moteurs JS, TypeScript, TC39 et autres). Si nous obtenons vraiment des modules ES qui peuvent fonctionner partout, cela vaut probablement la peine d'attendre, à mon humble avis.
Gratitude
Merci à Miles Borins pour ses commentaires sur ce post.
Ressources supplémentaires pour une lecture plus approfondie