Noeud 13.2.0 et supérieur
NodeJS 13.2.0 prend désormais en charge les modules ES sans indicateur 🎉 Cependant, l'implémentation est toujours marquée comme expérimentale, donc utilisez-la en production avec prudence.
Pour activer la prise en charge ESM dans 13.2.0, ajoutez ce qui suit à votre package.json:
{
"type": "module"
}
Tous .js, .mjs(ou fichiers sans extension) seront traitées comme ESM.
Il existe un certain nombre d'options différentes, autres que l' package.jsonopt-in complet , qui sont toutes détaillées dans la documentation de 13.2.0 .
Noeud 13.1.0 et inférieur
Ceux qui utilisent encore des versions plus anciennes de Node peuvent vouloir essayer le chargeur de module esm , qui est une implémentation prête pour la production de la spécification ES Modules pour NodeJS:
node -r esm main.js
Mises à jour détaillées ...
23 avril 2019
Un PR a récemment atterri pour changer la façon dont les modules ES sont détectés:
https://github.com/nodejs/node/pull/26745
C'est toujours derrière le --experimental-modulesdrapeau, mais il y a des changements majeurs dans la façon dont les modules peuvent être chargés:
package.typequi peut être soit moduleoucommonjs
type: "commonjs":
.js est analysé comme commonjs- par défaut pour le point d'entrée sans extension est commonjs
type: "module":
.js est analysé comme esm- ne prend pas en charge le chargement de JSON ou du module natif par défaut
- par défaut pour le point d'entrée sans extension est esm
--type=[mode]pour vous permettre de définir le type sur le point d'entrée. Remplacera le package.typepoint d'entrée.- Une nouvelle extension de fichier
.cjs.
- c'est spécifiquement pour prendre en charge l'importation de commonjs dans le
modulemode.
- ce n'est que dans le chargeur esm, le chargeur commonjs reste intact, mais l'extension fonctionnera dans l'ancien chargeur si vous utilisez le chemin d'accès complet au fichier.
--es-module-specifier-resolution=[type]
- les options sont
explicit(par défaut) etnode
- par défaut, notre chargeur ne permettra pas d'extensions optionnelles lors de l'importation, le chemin d'accès d'un module doit inclure l'extension s'il y en a une
- par défaut, notre chargeur ne permettra pas d'importer des répertoires qui ont un fichier d'index
- les développeurs peuvent utiliser
--es-module-specifier-resolution=nodepour activer l'algorithme de résolution de spécificateur commonjs
- Ce n'est pas une «fonctionnalité» mais plutôt une implémentation pour l'expérimentation. Il devrait changer avant la suppression du drapeau
--experimental-json-loader
- la seule façon d'importer json lorsque
"type": "module"
- quand activer tout
import 'thing.json'passera par le chargeur expérimental indépendant du mode
- basé sur whatwg / html # 4315
- Vous pouvez utiliser
package.mainpour définir un point d'entrée pour un module
- les extensions de fichiers utilisées dans main seront résolues en fonction du type de module
17 janvier 2019
Le nœud 11.6.0 répertorie toujours les modules ES comme expérimentaux, derrière un indicateur.
13 septembre 2017
NodeJS 8.5.0 a été publié avec la prise en charge des fichiers mjs derrière un indicateur:
node --experimental-modules index.mjs
Le plan pour cela est de supprimer l'indicateur de la version v10.0 LTS.
--Informations obsolètes. Conservé ici à des fins historiques -
8 septembre 2017
La branche principale NodeJS a été mise à jour avec la prise en charge initiale des modules ESM:
https://github.com/nodejs/node/commit/c8a389e19f172edbada83f59944cad7cc802d9d5
Celui-ci devrait être disponible dans la dernière nuit (il peut être installé via nvm pour fonctionner en parallèle de votre installation existante):
https://nodejs.org/download/nightly/
Et activé derrière le --experimental-modulesdrapeau:
package.json
{
"name": "testing-mjs",
"version": "1.0.0",
"description": "",
"main": "index.mjs" <-- Set this to be an mjs file
}
Exécutez ensuite:
node --experimental-modules .
Février 2017:
https://medium.com/@jasnell/an-update-on-es6-modules-in-node-js-42c958b890c#.6ye7mtn37
Les gars de NodeJS ont décidé que la moins mauvaise solution était d'utiliser l' .mjsextension de fichier. Les enseignements à en tirer sont les suivants:
En d'autres termes, étant donné deux fichiers foo.jset bar.mjs, l'utilisation import *
from 'foo'sera traitée foo.jscomme CommonJS tandis que import * from 'bar'
sera bar.mjstraitée comme un module ES6
Et quant aux délais ...
À l'heure actuelle, il y a encore un certain nombre de problèmes de spécification et d'implémentation qui doivent se produire du côté ES6 et de la machine virtuelle avant que Node.js puisse même commencer à travailler sur une implémentation supportable des modules ES6. Les travaux sont en cours mais cela va prendre un certain temps - Nous envisageons actuellement environ un an au moins .
Octobre 2016:
L'un des développeurs de Node.JS a récemment assisté à une réunion TC-39 et a rédigé un superbe article sur les bloqueurs à implémenter pour Node.JS:
https://hackernoon.com/node-js-tc-39-and-modules-a1118aecf95e
Le point à retenir de base est:
- Les modules ES sont analysés statiquement, les CommonJS sont évalués
- Les modules CommonJS permettent d'exporter des correctifs de singe, les modules ES ne le font pas actuellement
- Il est difficile de détecter ce qu'est un module ES et ce qui est CommonJS sans une certaine forme d'entrée utilisateur, mais ils essaient.
*.mjs semble la solution la plus probable, à moins qu'ils ne puissent détecter avec précision un module ES sans intervention de l'utilisateur
- Réponse originale -
Cela a été une patate chaude pendant un certain temps. En fin de compte, oui, Node prendra éventuellement en charge la syntaxe ES2015 pour l'importation / exportation de modules - très probablement lorsque les spécifications pour le chargement des modules seront finalisées et acceptées.
Voici un bon aperçu de ce qui retient NodeJS. Essentiellement, ils doivent s'assurer que la nouvelle spécification fonctionne pour Node qui est principalement un chargement synchrone conditionnel et également pour HTML qui est principalement asynchrone.
Personne ne le sait pour le moment, mais j'imagine que Node prendra en charge import/exportle chargement statique, en plus du nouveau System.importpour le chargement dynamique - tout en conservant le requirecode hérité.
Voici quelques propositions sur la façon dont Node pourrait y parvenir:
node es2015 modules, affiche les résultats suivants comme l'un des meilleurs résultats: github.com/nodejs/node/wiki/ES6-Module-Detection-in-Node .