web-dev-qa-db-fra.com

NodeJS prévoit de prendre en charge les modules d'importation / exportation es6 (es2015)

J'ai cherché partout sur Internet sans réponse claire à ce sujet.

Actuellement, NodeJS utilise uniquement la syntaxe CommonJS pour charger les modules. Si vous souhaitez vraiment utiliser la syntaxe standard des modules ES2015, vous devez soit la transpiler au préalable, soit utiliser un chargeur de modules externe au moment de l'exécution.

Actuellement, je ne suis pas trop optimiste pour utiliser l'une ou l'autre de ces méthodes. Les responsables de la maintenance de NodeJS prévoient-ils même de prendre en charge les modules ES2015 ou non? Je n'ai rien trouvé à ce sujet.

À l'heure actuelle, NodeJS 6.x prétend prendre en charge 96% des fonctionnalités de l'ES2015, mais il n'y a aucune référence aux modules ( lien de support NodeJS ES2105 ).

Savez-vous si NodeJS prendra en charge ces modules immédiatement, dans un avenir rapproché?

javascriptnode.jsmoduleecmascript-6es6-modules
262
Zorgatone

tl; dr

Latest NodeJS répertorie toujours les modules ES comme expérimentaux, derrière un drapeau.

Ceux qui recherchent une solution au problème voudront peut-être essayer le chargeur de modules esm , qui est une implémentation prête à la production de la spécification ES Modules pour NodeJS:

node -r esm main.js

Mises à jour détaillées ...

23 avril 2019

Un RP récemment débarqué pour changer la façon dont les modules ES sont détectés: https://github.com/nodejs/node/pull/26745

Il est toujours derrière le drapeau --experimental-modules, mais il y a des changements majeurs dans la façon dont les modules peuvent être chargés:

  • package.type qui peut être module ou commonjs
    • type: "commonjs":
    • .js est analysé comme commonjs
    • par défaut, 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 de Native Module par défaut
    • la valeur 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. Annulera package.type pour le point d'entrée.
  • Une nouvelle extension de fichier .cjs.
    • ceci est spécifiquement pour supporter l'importation de commonjs dans le mode module.
    • c'est uniquement dans le chargeur esm, le chargeur commonjs reste inchangé, 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 (valeur par défaut) et node
    • par défaut, notre chargeur n'autorisera pas d'extensions optionnelles dans l'importation, le chemin d'accès d'un module doit inclure l'extension s'il en existe une
    • par défaut, notre chargeur ne permet pas l'importation de répertoires contenant un fichier d'index
    • les développeurs peuvent utiliser --es-module-specifier-resolution=node pour activer l'algorithme de résolution du spécificateur commonjs
    • Ce n'est pas une "fonctionnalité" mais plutôt une implémentation pour l'expérimentation. On s'attend à ce qu'il change avant que le drapeau ne soit retiré
  • --experimental-json-loader
    • le seul moyen d'importer JSON lorsque "type": "module"
    • quand enable tout import 'thing.json' passera par le chargeur expérimental indépendamment du mode
    • basé sur whatwg/html # 4315
  • Vous pouvez utiliser package.main pour définir un point d'entrée pour un module
    • les extensions de fichier utilisées dans main seront résolues en fonction du type du module

17 janvier 2019

Node 11.6. indique toujours que les modules ES sont expérimentaux, derrière un drapeau.

13 septembre 2017

NodeJS 8.5. a été publié avec la prise en charge des fichiers mjs derrière un indicateur:

node --experimental-modules index.mjs

L'objectif est de supprimer l'indicateur pour la version 10.0 LTS.

- Information obsolète. Conservé ici à des fins historiques -

8 septembre 2017

La branche principale de NodeJS a été mise à jour avec la prise en charge initiale des modules ESM:
https://github.com/nodejs/node/commit/c8a389e19f172edbada83f59944cad7cc802d9d5

Cela devrait être disponible dans la dernière nuit (cela peut être installé via nvm pour être exécuté parallèlement à votre installation existante):
https://nodejs.org/download/nightly/

Et activé derrière le drapeau --experimental-modules:

package.json 

{
  "name": "testing-mjs",
  "version": "1.0.0",
  "description": "",
  "main": "index.mjs" <-- Set this to be an mjs file
}

Puis lancez:

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 solution la moins mauvaise consiste à utiliser l'extension de fichier .mjs. La conclusion de ceci est:

En d'autres termes, étant donné deux fichiers foo.js et bar.mjs, utiliser import * from 'foo' traitera foo.js comme CommonJS tandis que import * from 'bar' traitera bar.mjs comme un ES6. Module

Et comme pour les délais ...

À l’heure actuelle, il reste encore un certain nombre de problèmes de spécification et d’implémentation à résoudre du côté de l’ES6 et de la machine virtuelle avant que Node.js puisse même commencer à travailler sur une implémentation supportable de modules ES6. Les travaux sont en cours, mais cela va prendre du temps. Nous examinons actuellement environ un an au moins .

Octobre 2016:

L'un des développeurs de Node.JS a récemment participé à une réunion du 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 principe de base de cela est:

  • Les modules ES sont analysés statiquement, les CommonJS sont évalués
  • Les modules CommonJS autorisent les exportations par patch-singe, les modules ES ne le sont pas pour le moment.
  • Il est difficile de détecter ce qu'est un module ES et ce qui est CommonJS sans une certaine forme de saisie de l'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 fait longtemps que la patate est chaude. L’essentiel est que oui, Node supportera éventuellement la syntaxe ES2015 pour l’import/export de modules - très probablement lorsque le spécifications de chargement des modules est finalisé et approuvé.

Voici n bon aperç de ce qui maintient NodeJS en place. Pour l'essentiel, ils doivent s'assurer que la nouvelle spécification fonctionne pour Node, qui est principalement un chargement conditionnel, synchrone et HTML, qui est principalement asynchrone.

Personne ne le sait pour le moment, mais j'imagine que Node prendra en charge import/export pour le chargement statique, en plus du nouveau System.import pour le chargement dynamique - tout en conservant require pour le code hérité.

Voici quelques propositions sur la façon dont Node pourrait y parvenir:

288
CodingIntrigue