Aktueller Supportstatus für ECMAScript-Module (ESMs) in Node.js:
- Die experimentelle ESM-Unterstützung wurde am 12. September 2017 in Node.js 8.5.0 hinzugefügt.
- Danach bildete das Technical Steering Committee von Node.js das Team, das für das Modules-Team verantwortlich ist , um die fehlenden Teile für die bevorstehende (nicht experimentelle) Veröffentlichung zu entwerfen. Dieses Team besteht aus Mitarbeitern aus verschiedenen Webentwicklungsbranchen (Frontend, Backend, JS-Engines usw.).
Im Oktober veröffentlichte das Modules Team den "New Modules Implementation Plan" . Dieser Beitrag erklärt, was es enthält.
Phasen
Der Prozess ist in drei Phasen unterteilt:
- Phase 1: Erstellen Sie einen "minimalen" Kern - die grundlegenden Regeln und Funktionen, so minimal und sicher wie möglich.
- Ab Phase 2: Erstellen komplexerer Funktionen basierend auf dem Kernel.
Ein minimaler Kern wird die Grundlage für zukünftige Arbeiten sein. Das neue Design wird auch die derzeitige experimentelle Implementierung ersetzen, sobald ähnliche Funktionen erworben wurden.
Phase 1: Mindestunterstützung für Core-ESM in Node.js.
Vereinfachung der Modulkennungen
Eines der Ziele von Modules Team ist es, eine „Browser-Äquivalenz“ zu erreichen: Node.js sollte so nah wie möglich an Browsern sein. Der Kernel erreicht dies, indem er das Parsen von Modul-IDs (URLs, die auf Module verweisen) vereinfacht:
- Jede Modulkennung muss mit einem Dateinamen mit der Erweiterung enden. Also
- Erweiterungen werden nicht automatisch hinzugefügt
- Das Importieren von Verzeichnissen wird nicht unterstützt (entweder durch Umleitung nach
dir/index.mjs oder durch Lesen des Hauptfelds in package.json ).
- ES-Module können integrierte Node.js-Module (
path und dergleichen) importieren. Sie sind die einzige Ausnahme von der vorherigen Regel. - Standardmäßig werden nur Dateien mit der Erweiterung
.mjs (siehe Phase 2, wenn Sie am Status anderer Erweiterungen interessiert sind). Daher können andere Modultypen nicht durch import importiert werden: CommonJS-Module, JSON-Dateien, native Module.
Grundlegende CommonJS-Funktionen für ES-Module
- URL des aktuellen Moduls (ähnlich
__filename von CommonJS): import.meta.url - ES-Module dynamisch importieren (verfügbar über
require() in CommonJS): import()
Kompatibilität
- ES-Module können CommonJS-Module über
createRequireFromPath() importieren. Dies funktioniert wie folgt (es ist geplant, eine abgekürzte Methode zu createRequireFromUrl() , z. B. die Funktion 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');
- CommonJS-Module können ES-Module über
import() laden.
Phase 2 und Zukunftspläne
- In der zweiten Phase warten wir auf:
- Unterstützung für "nackte" Kennungen wie
'lodash' . Dies beinhaltet höchstwahrscheinlich eine Möglichkeit, diese Bezeichner realen Pfaden zuzuordnen. - Unterstützung für andere Dateierweiterungen neben
.mjs . Dies beinhaltet unter anderem die Unterstützung von ES-Modulen in .js Dateien.
- Phase 3 wird sich höchstwahrscheinlich auf Modullader mit Erweiterungspunkten konzentrieren, an denen Benutzer ihre Logik anschließen können.
Wann kann ich ES-Module in Node.js verwenden?
- Hinter der Flagge: ab sofort verfügbar
- Warnung: Das Verhalten stimmt noch nicht mit dem oben in Phase 1 beschriebenen überein (Stand Node.js 11.5.0).
- Ohne Flagge und gemäß Phase 1: Modules Team versucht dies so schnell wie möglich zu ermöglichen. Wir hoffen, dass die Module in Node.js 14 (April 2020) unter der Flagge veröffentlicht und nach Möglichkeit auf frühere Versionen portiert werden.
Häufig gestellte Fragen
- Warum brauche ich eine neue
.mjs Dateierweiterung?
- Jede Entscheidung zur Unterscheidung zwischen ESM- und CommonJS-Formaten hat ihre Vor- und Nachteile. Die Verwendung einer separaten Auflösung scheint eine gute Option zu sein ( weitere Informationen ).
- Warum sollte sich Node.js wie ein Browser verhalten?
- Weil es die Wiederverwendung von Code ermöglicht. Zum Beispiel, um Bibliotheken zu erstellen, die sowohl in Browsern als auch in Node.js funktionieren
- Dies sollte auch das Umschalten zwischen Backend und Frontend während der Codierung erleichtern.
- Warum all diese Einschränkungen für die Kompatibilität?
- Es gibt ziemlich starke Unterschiede zwischen den ES- und CommonJS-Modulen in der Struktur (statisch versus dynamisch) und der Art des Ladens (asynchron versus synchron). Einschränkungen helfen dabei, die Dinge einfach zu halten - da auf lange Sicht die überwiegende Mehrheit aus ES-Modulen bestehen wird.
- Warum dauert das alles so lange?
- Hier sind viele Stakeholder und viele verschiedene Plattformen beteiligt (Node.js, npm, Browser, JS-Engines, TypeScript, TC39 und andere). Wenn wir wirklich ES-Module bekommen, die überall funktionieren können, lohnt sich das Warten wahrscheinlich, IMHO.
Dankbarkeit
Vielen Dank an Miles Borins für sein Feedback zu diesem Beitrag.
Zusätzliche Ressourcen zur weiteren Lektüre