Module: ECMAScript-Module

[Historie]

Version	Änderungen
v23.1.0	Import-Attribute sind nicht mehr experimentell.
v22.0.0	Unterstützung für Import-Assertions entfernt.
v21.0.0, v20.10.0, v18.20.0	Experimentelle Unterstützung für Import-Attribute hinzugefügt.
v20.0.0, v18.19.0	Module-Anpassungshooks werden außerhalb des Hauptthreads ausgeführt.
v18.6.0, v16.17.0	Unterstützung für das Verketten von Module-Anpassungshooks hinzugefügt.
v17.1.0, v16.14.0	Experimentelle Unterstützung für Import-Assertions hinzugefügt.
v17.0.0, v16.12.0	Konsolidierung von Anpassungshooks, entfernt `getFormat`, `getSource`, `transformSource` und `getGlobalPreloadCode` Hooks; hinzugefügt `load` und `globalPreload` Hooks; erlaubt die Rückgabe von `format` von entweder `resolve` oder `load` Hooks.
v14.8.0	Top-Level-Await-Flag entfernt.
v15.3.0, v14.17.0, v12.22.0	Stabilisierung der Module-Implementierung.
v14.13.0, v12.20.0	Unterstützung für die Erkennung von CommonJS-Named-Exports.
v14.0.0, v13.14.0, v12.20.0	Warnung für experimentelle Module entfernt.
v13.2.0, v12.17.0	Das Laden von ECMAScript-Modulen erfordert kein Befehlszeilenflag mehr.
v12.0.0	Unterstützung für ES-Module mit der Dateierweiterung `.js` über das Feld `"type"` in `package.json` hinzugefügt.
v8.5.0	Hinzugefügt in: v8.5.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

Einführung

ECMAScript-Module sind das offizielle Standardformat, um JavaScript-Code für die Wiederverwendung zu verpacken. Module werden unter Verwendung verschiedener import und export Anweisungen definiert.

Das folgende Beispiel eines ES-Moduls exportiert eine Funktion:

// addTwo.mjs
function addTwo(num) {
  return num + 2
}

export { addTwo }

Das folgende Beispiel eines ES-Moduls importiert die Funktion aus addTwo.mjs:

// app.mjs
import { addTwo } from './addTwo.mjs'

// Gibt aus: 6
console.log(addTwo(4))

Node.js unterstützt ECMAScript-Module vollständig, wie sie derzeit spezifiziert sind, und bietet Interoperabilität zwischen ihnen und seinem ursprünglichen Modulformat, CommonJS.

Aktivieren

Node.js verfügt über zwei Modulsysteme: CommonJS-Module und ECMAScript-Module.

Autoren können Node.js mitteilen, JavaScript als ES-Modul zu interpretieren, über die Dateiendung .mjs, das Feld package.json "type" mit dem Wert "module" oder das Flag --input-type mit dem Wert "module". Dies sind explizite Markierungen für Code, der als ES-Modul ausgeführt werden soll.

Umgekehrt können Autoren Node.js explizit mitteilen, JavaScript als CommonJS zu interpretieren, über die Dateiendung .cjs, das Feld package.json "type" mit dem Wert "commonjs" oder das Flag --input-type mit dem Wert "commonjs".

Wenn dem Code explizite Markierungen für ein Modulsystem fehlen, untersucht Node.js den Quellcode eines Moduls auf ES-Modulsyntax. Wird solche Syntax gefunden, führt Node.js den Code als ES-Modul aus; andernfalls führt es das Modul als CommonJS aus. Weitere Details finden Sie unter Bestimmung des Modulsystems.

Packages

Dieser Abschnitt wurde nach Module: Packages verschoben.

`import`-Spezifizierer

Terminologie

Der Spezifizierer einer import-Anweisung ist die Zeichenkette nach dem from-Schlüsselwort, z. B. 'node:path' in import { sep } from 'node:path'. Spezifizierer werden auch in export from-Anweisungen und als Argument für einen import()-Ausdruck verwendet.

Es gibt drei Arten von Spezifizierern:

Relative Spezifizierer wie './startup.js' oder '../config.mjs'. Sie verweisen auf einen Pfad relativ zum Speicherort der importierenden Datei. Die Dateierweiterung ist hierfür immer notwendig.
Bare Spezifizierer wie 'some-package' oder 'some-package/shuffle'. Sie können sich auf den Haupteinstiegspunkt eines Packages anhand des Package-Namens oder auf ein spezifisches Feature-Modul innerhalb eines Packages beziehen, das dem Package-Namen vorangestellt ist, wie in den Beispielen angegeben. Die Einbeziehung der Dateierweiterung ist nur für Packages ohne ein Feld "exports" notwendig.
Absolute Spezifizierer wie 'file:///opt/nodejs/config.js'. Sie verweisen direkt und explizit auf einen vollständigen Pfad.

Die Auflösung von Bare-Spezifizierern wird vom Node.js-Modul-Auflösungs- und Ladealgorithmus behandelt. Alle anderen Spezifiziererauflösungen werden immer nur mit der standardmäßigen relativen URL-Auflösungssemantik aufgelöst.

Wie in CommonJS können Moduldateien innerhalb von Packages durch Anhängen eines Pfads an den Package-Namen zugegriffen werden, es sei denn, die package.json des Packages enthält ein Feld "exports". In diesem Fall können auf Dateien innerhalb von Packages nur über die in "exports" definierten Pfade zugegriffen werden.

Einzelheiten zu diesen Package-Auflösungsregeln, die für Bare-Spezifizierer in der Node.js-Modulauflösung gelten, finden Sie in der Packages-Dokumentation.

Obligatorische Dateierweiterungen

Bei Verwendung des Schlüsselworts import zur Auflösung relativer oder absoluter Bezeichner muss eine Dateierweiterung angegeben werden. Verzeichnisindizes (z. B. './startup/index.js') müssen ebenfalls vollständig angegeben werden.

Dieses Verhalten entspricht dem Verhalten von import in Browserumgebungen, vorausgesetzt, ein typisch konfigurierter Server wird verwendet.

URLs

ES-Module werden als URLs aufgelöst und zwischengespeichert. Dies bedeutet, dass Sonderzeichen prozentcodiert werden müssen, z. B. # mit %23 und ? mit %3F.

Die URL-Schemata file:, node: und data: werden unterstützt. Ein Bezeichner wie 'https://example.com/app.js' wird in Node.js nicht nativ unterstützt, es sei denn, ein benutzerdefinierter HTTPS-Loader wird verwendet.

`file:`-URLs

Module werden mehrmals geladen, wenn der import-Bezeichner, der zur Auflösung verwendet wird, eine andere Abfrage oder ein anderes Fragment aufweist.

import './foo.mjs?query=1' // lädt ./foo.mjs mit der Abfrage "?query=1"
import './foo.mjs?query=2' // lädt ./foo.mjs mit der Abfrage "?query=2"

Das Stammverzeichnis kann über /, // oder file:/// referenziert werden. Angesichts der Unterschiede zwischen URL und Pfadauflösung (z. B. Details zur Prozentcodierung) wird empfohlen, url.pathToFileURL zu verwenden, wenn ein Pfad importiert wird.

`data:`-Importe

Hinzugefügt in: v12.10.0

data:-URLs werden für den Import mit den folgenden MIME-Typen unterstützt:

text/javascript für ES-Module
application/json für JSON
application/wasm für Wasm

import 'data:text/javascript,console.log("hello!");';
import _ from 'data:application/json,"world!"' with { type: 'json' };

data:-URLs lösen nur Bare Specifier für integrierte Module und absolute Bezeichner auf. Die Auflösung von relativen Bezeichnern funktioniert nicht, da data: kein speziales Schema ist. Beispielsweise schlägt der Versuch, ./foo aus data:text/javascript,import "./foo"; zu laden, fehl, da es kein Konzept der relativen Auflösung für data:-URLs gibt.

`node:`-Importe

[Verlauf]

Version	Änderungen
v16.0.0, v14.18.0	Unterstützung für `node:`-Importe zu `require(...)` hinzugefügt.
v14.13.1, v12.20.0	Hinzugefügt in: v14.13.1, v12.20.0

node:-URLs werden als alternative Methode zum Laden von integrierten Node.js-Modulen unterstützt. Dieses URL-Schema ermöglicht die Referenzierung integrierter Module durch gültige absolute URL-Strings.

import fs from 'node:fs/promises'

Importattribute

[Verlauf]

Version	Änderungen
v21.0.0, v20.10.0, v18.20.0	Umstellung von Import Assertions auf Import Attribute.
v17.1.0, v16.14.0	Hinzugefügt in: v17.1.0, v16.14.0

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

Importattribute sind eine Inline-Syntax für Modul-Importanweisungen, um neben dem Modul-Spezifizierer weitere Informationen zu übergeben.

import fooData from './foo.json' with { type: 'json' };

const { default: barData } =
  await import('./bar.json', { with: { type: 'json' } });

Node.js unterstützt nur das Attribut type, für das es die folgenden Werte unterstützt:

Attribut `type`	Erforderlich für
`'json'`	JSON-Module

Das Attribut type: 'json' ist obligatorisch beim Importieren von JSON-Modulen.

Integrierte Module

Integrierte Module bieten benannte Exporte ihrer öffentlichen API. Ein Standard-Export wird ebenfalls bereitgestellt, der der Wert der CommonJS-Exporte ist. Der Standard-Export kann unter anderem verwendet werden, um die benannten Exporte zu modifizieren. Benannte Exporte integrierter Module werden nur durch Aufrufen von module.syncBuiltinESMExports() aktualisiert.

import EventEmitter from 'node:events'
const e = new EventEmitter()

import { readFile } from 'node:fs'
readFile('./foo.txt', (err, source) => {
  if (err) {
    console.error(err)
  } else {
    console.log(source)
  }
})

import fs, { readFileSync } from 'node:fs'
import { syncBuiltinESMExports } from 'node:module'
import { Buffer } from 'node:buffer'

fs.readFileSync = () => Buffer.from('Hello, ESM')
syncBuiltinESMExports()

fs.readFileSync === readFileSync

`import()`-Ausdrücke

Dynamisches import() wird sowohl in CommonJS- als auch in ES-Modulen unterstützt. In CommonJS-Modulen kann es verwendet werden, um ES-Module zu laden.

`import.meta`

<Objekt>

Die Meta-Eigenschaft import.meta ist ein Objekt, das die folgenden Eigenschaften enthält. Sie wird nur in ES-Modulen unterstützt.

`import.meta.dirname`

Hinzugefügt in: v21.2.0, v20.11.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.2 - Release Candidate

<Zeichenkette> Der Verzeichnisname des aktuellen Moduls. Dies ist dasselbe wie path.dirname() von import.meta.filename.

`import.meta.filename`

Hinzugefügt in: v21.2.0, v20.11.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.2 - Release Candidate

<Zeichenkette> Der vollständige absolute Pfad und Dateiname des aktuellen Moduls, wobei symbolische Links aufgelöst werden.
Dies ist dasselbe wie url.fileURLToPath() von import.meta.url.

`import.meta.url`

<Zeichenkette> Die absolute file:-URL des Moduls.

Dies ist genau so definiert wie in Browsern, die die URL der aktuellen Moduldatei bereitstellen.

Dies ermöglicht nützliche Muster wie das relative Laden von Dateien:

import { readFileSync } from 'node:fs'
const buffer = readFileSync(new URL('./data.proto', import.meta.url))

`import.meta.resolve(specifier)`

[Verlauf]

Version	Änderungen
v20.6.0, v18.19.0	Nicht mehr hinter dem `--experimental-import-meta-resolve` CLI-Flag, außer für den nicht standardmäßigen `parentURL`-Parameter.
v20.6.0, v18.19.0	Diese API löst jetzt keinen Fehler mehr aus, wenn auf `file:`-URLs abgezielt wird, die keiner bestehenden Datei auf dem lokalen FS zugeordnet sind.
v20.0.0, v18.19.0	Diese API gibt jetzt synchron eine Zeichenkette zurück, anstatt ein Promise.
v16.2.0, v14.18.0	Unterstützung für WHATWG `URL`-Objekt für den `parentURL`-Parameter hinzugefügt.
v13.9.0, v12.16.2	Hinzugefügt in: v13.9.0, v12.16.2

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.2 - Release Candidate

specifier <Zeichenkette> Der Modul-Specifier, der relativ zum aktuellen Modul aufgelöst werden soll.
Rückgabewert: <Zeichenkette> Die absolute URL-Zeichenkette, auf die der Specifier aufgelöst würde.

import.meta.resolve ist eine modulrelative Auflösungsfunktion, die für jedes Modul Gültigkeit hat und die URL-Zeichenkette zurückgibt.

const dependencyAsset = import.meta.resolve('component-lib/asset.css')
// file:///app/node_modules/component-lib/asset.css
import.meta.resolve('./dep.js')
// file:///app/dep.js

Alle Funktionen der Node.js-Modulauflösung werden unterstützt. Abhängigkeitsauflösungen unterliegen den zulässigen Exportauﬂösungen innerhalb des Pakets.

Einschränkungen:

Dies kann zu synchronen Dateisystemoperationen führen, die die Leistung ähnlich wie require.resolve beeinträchtigen können.
Diese Funktion ist in benutzerdefinierten Loadern nicht verfügbar (es würde zu einer Deadlock-Situation führen).

Nicht standardmäßige API:

Bei Verwendung des Flags --experimental-import-meta-resolve akzeptiert diese Funktion ein zweites Argument:

parent <Zeichenkette> | <URL> Eine optionale absolute übergeordnete Modul-URL, von der aus aufgelöst werden soll. Standardwert: import.meta.url

Interoperabilität mit CommonJS

`import`-Anweisungen

Eine import-Anweisung kann auf ein ES-Modul oder ein CommonJS-Modul verweisen. import-Anweisungen sind nur in ES-Modulen zulässig, aber dynamische import()-Ausdrücke werden in CommonJS zum Laden von ES-Modulen unterstützt.

Beim Importieren von CommonJS-Modulen wird das module.exports-Objekt als Standard-Export bereitgestellt. Benannte Exporte können verfügbar sein, bereitgestellt durch statische Analyse als Komfort für eine bessere Ökosystemkompatibilität.

`require`

Das CommonJS-Modul require unterstützt derzeit nur das Laden synchroner ES-Module (d. h. ES-Module, die kein Top-Level await verwenden).

Einzelheiten finden Sie unter Laden von ECMAScript-Modulen mit require().

CommonJS-Namespaces

[Historie]

Version	Änderungen
v23.0.0	Hinzugefügt `'module.exports'` Export-Marker zu CJS-Namespaces.
v14.13.0	Hinzugefügt in: v14.13.0

CommonJS-Module bestehen aus einem module.exports-Objekt, das von beliebigem Typ sein kann.

Um dies zu unterstützen, wird beim Importieren von CommonJS aus einem ECMAScript-Modul ein Namespace-Wrapper für das CommonJS-Modul erstellt, der immer einen default-Export-Schlüssel bereitstellt, der auf den CommonJS module.exports-Wert verweist.

Zusätzlich wird eine heuristische statische Analyse des Quelltexts des CommonJS-Moduls durchgeführt, um eine Best-Effort-Liste statischer Exporte zu erhalten, die im Namespace aus Werten in module.exports bereitgestellt werden sollen. Dies ist notwendig, da diese Namespaces vor der Auswertung des CJS-Moduls erstellt werden müssen.

Diese CommonJS-Namespace-Objekte stellen den default-Export auch als benannten Export 'module.exports' bereit, um eindeutig anzugeben, dass ihre Darstellung in CommonJS diesen Wert und nicht den Namespace-Wert verwendet. Dies spiegelt die Semantik der Behandlung des Exportnamens 'module.exports' in der require(esm)-Interop-Unterstützung wider.

Beim Importieren eines CommonJS-Moduls kann es zuverlässig mit dem ES-Modul-Standard-Import oder der entsprechenden syntaktischen Vereinfachung importiert werden:

import { default as cjs } from 'cjs'
// Identisch mit dem obigen
import cjsSugar from 'cjs'

console.log(cjs)
console.log(cjs === cjsSugar)
// Gibt aus:
//   <module.exports>
//   true

Dieses Modul-Namespace-exotitische Objekt kann direkt beobachtet werden, entweder mit import * as m from 'cjs' oder einem dynamischen Import:

import * as m from 'cjs'
console.log(m)
console.log(m === (await import('cjs')))
// Gibt aus:
//   [Module] { default: <module.exports>, 'module.exports': <module.exports> }
//   true

Für eine bessere Kompatibilität mit der bestehenden Verwendung im JS-Ökosystem versucht Node.js zusätzlich, die benannten CommonJS-Exporte jedes importierten CommonJS-Moduls zu bestimmen, um sie mithilfe eines statischen Analyseprozesses als separate ES-Modul-Exporte bereitzustellen.

Betrachten Sie beispielsweise ein geschriebenes CommonJS-Modul:

// cjs.cjs
exports.name = 'exported'

Das vorhergehende Modul unterstützt benannte Importe in ES-Modulen:

import { name } from './cjs.cjs'
console.log(name)
// Gibt aus: 'exported'

import cjs from './cjs.cjs'
console.log(cjs)
// Gibt aus: { name: 'exported' }

import * as m from './cjs.cjs'
console.log(m)
// Gibt aus:
//   [Module] {
//     default: { name: 'exported' },
//     'module.exports': { name: 'exported' },
//     name: 'exported'
//   }

Wie im letzten Beispiel des protokollierten Modul-Namespace-exotitischen Objekts zu sehen ist, wird der name-Export aus dem module.exports-Objekt kopiert und direkt im ES-Modul-Namespace gesetzt, wenn das Modul importiert wird.

Live-Bindungsaktualisierungen oder neue Exporte, die zu module.exports hinzugefügt werden, werden für diese benannten Exporte nicht erkannt.

Die Erkennung benannter Exporte basiert auf gängigen Syntaxmustern, erkennt aber nicht immer korrekt benannte Exporte. In diesen Fällen kann die oben beschriebene Verwendung des Standard-Importformulars eine bessere Option sein.

Die Erkennung benannter Exporte umfasst viele gängige Exportmuster, Reexportmuster und Ausgaben von Build-Tools und Transpilern. Die genau implementierte Semantik finden Sie unter cjs-module-lexer.

Unterschiede zwischen ES-Modulen und CommonJS

Kein `require`, `exports` oder `module.exports`

In den meisten Fällen kann das ES-Modul import zum Laden von CommonJS-Modulen verwendet werden.

Falls erforderlich, kann eine require-Funktion innerhalb eines ES-Moduls mithilfe von module.createRequire() erstellt werden.

Kein `filename` oder `dirname`

Diese CommonJS-Variablen sind in ES-Modulen nicht verfügbar.

__filename und __dirname Anwendungsfälle können über import.meta.filename und import.meta.dirname repliziert werden.

Kein Addon-Laden

Addons werden derzeit nicht mit ES-Modul-Imports unterstützt.

Sie können stattdessen mit module.createRequire() oder process.dlopen geladen werden.

Kein `require.resolve`

Die relative Auflösung kann über new URL('./local', import.meta.url) behandelt werden.

Für einen vollständigen Ersatz von require.resolve gibt es die import.meta.resolve API.

Alternativ kann module.createRequire() verwendet werden.

Kein `NODE_PATH`

NODE_PATH ist kein Bestandteil der Auflösung von import-Spezifizierern. Bitte verwenden Sie symbolische Links, wenn dieses Verhalten gewünscht ist.

Kein `require.extensions`

require.extensions wird von import nicht verwendet. Module-Anpassungshooks können einen Ersatz bieten.

Kein `require.cache`

require.cache wird von import nicht verwendet, da der ES-Modul-Loader einen eigenen separaten Cache besitzt.

JSON-Module

[Historie]

Version	Änderungen
v23.1.0	JSON-Module sind nicht mehr experimentell.

[Stabil: 2 - Stabil]

Stabil: 2 Stabilität: 2 - Stabil

JSON-Dateien können über import referenziert werden:

import packageConfig from './package.json' with { type: 'json' };

Die Syntax with { type: 'json' } ist obligatorisch; siehe Import-Attribute.

Das importierte JSON stellt nur einen default-Export bereit. Es gibt keine Unterstützung für benannte Exporte. Ein Cache-Eintrag wird im CommonJS-Cache erstellt, um Duplikate zu vermeiden. Das gleiche Objekt wird in CommonJS zurückgegeben, wenn das JSON-Modul bereits vom gleichen Pfad importiert wurde.

Wasm-Module

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Das Importieren von WebAssembly-Modulen wird unter der Flagge --experimental-wasm-modules unterstützt. Dies ermöglicht das Importieren beliebiger .wasm-Dateien als normale Module und unterstützt gleichzeitig deren Moduleimporte.

Diese Integration entspricht dem ES-Modul-Integrationsvorschlag für WebAssembly.

Beispielsweise eine index.mjs mit folgendem Inhalt:

import * as M from './module.wasm'
console.log(M)

ausgeführt unter:

bash

node --experimental-wasm-modules index.mjs

würde die Exportschnittstelle für die Instanziierung von module.wasm bereitstellen.

Top-Level `await`

Hinzugefügt in: v14.8.0

Das await-Schlüsselwort kann im Top-Level-Body eines ECMAScript-Moduls verwendet werden.

Angenommen, eine a.mjs mit

export const five = await Promise.resolve(5)

Und eine b.mjs mit

import { five } from './a.mjs'

console.log(five) // Gibt `5` aus

bash

node b.mjs # funktioniert

Wenn ein Top-Level await-Ausdruck niemals aufgelöst wird, beendet der node-Prozess mit einem 13 Statuscode.

import { spawn } from 'node:child_process'
import { execPath } from 'node:process'

spawn(execPath, [
  '--input-type=module',
  '--eval',
  // Promise, die niemals aufgelöst wird:
  'await new Promise(() => {})',
]).once('exit', code => {
  console.log(code) // Gibt `13` aus
})

Loader

Die vorherige Loader-Dokumentation befindet sich jetzt unter Module: Anpassungshooks.

Auflösungs- und Ladealgorithmus

Eigenschaften

Der Standard-Resolver hat folgende Eigenschaften:

FileURL-basierte Auflösung, wie sie von ES-Modulen verwendet wird
Relative und absolute URL-Auflösung
Keine Standarderweiterungen
Keine Ordner-Mains
Suche nach Bare-Specifier-Paket-Auflösung über node_modules
Scheitert nicht bei unbekannten Erweiterungen oder Protokollen
Kann optional einen Hinweis auf das Format an die Ladephase liefern

Der Standard-Loader hat folgende Eigenschaften:

Unterstützung für das Laden von integrierten Modulen über node:-URLs
Unterstützung für das Laden von "inline"-Modulen über data:-URLs
Unterstützung für das Laden von file:-Modulen
Scheitert bei jedem anderen URL-Protokoll
Scheitert bei unbekannten Erweiterungen für das Laden von file: (unterstützt nur .cjs, .js und .mjs)

Auflösungsalgorithmus

Der Algorithmus zum Laden eines ES-Modul-Spezifikators wird durch die unten angegebene Methode ESM_RESOLVE bereitgestellt. Sie gibt die aufgelöste URL für einen Modul-Spezifikator relativ zu einer parentURL zurück.

Der Auflösungsalgorithmus bestimmt die vollständige aufgelöste URL für einen Modul-Ladevorgang zusammen mit dem vorgeschlagenen Modulformat. Der Auflösungsalgorithmus bestimmt nicht, ob das Protokoll der aufgelösten URL geladen werden kann oder ob die Dateierweiterungen zulässig sind. Diese Validierungen werden stattdessen von Node.js während der Ladevorgangs durchgeführt (z. B. wenn das Laden einer URL mit einem Protokoll angefordert wurde, das nicht file:, data: oder node: ist).

Der Algorithmus versucht auch, das Format der Datei basierend auf der Erweiterung zu bestimmen (siehe Algorithmus ESM_FILE_FORMAT unten). Wenn die Dateierweiterung nicht erkannt wird (z. B. wenn es nicht .mjs, .cjs oder .json ist), wird ein Format von undefined zurückgegeben, was während der Ladevorgangs einen Fehler auslöst.

Der Algorithmus zur Bestimmung des Modulformats einer aufgelösten URL wird von ESM_FILE_FORMAT bereitgestellt, der das eindeutige Modulformat für jede Datei zurückgibt. Das Format "module" wird für ein ECMAScript-Modul zurückgegeben, während das Format "commonjs" verwendet wird, um das Laden über den Legacy-CommonJS-Loader anzuzeigen. Zusätzliche Formate wie "addon" können in zukünftigen Updates erweitert werden.

In den folgenden Algorithmen werden alle Unterprogrammfehler, sofern nicht anders angegeben, als Fehler dieser Top-Level-Routinen weitergegeben.

defaultConditions ist das Array mit den bedingten Umgebungsnamen, ["node", "import"].

Der Resolver kann die folgenden Fehler auslösen:

Ungültiger Modul-Spezifikator: Der Modul-Spezifikator ist eine ungültige URL, ein ungültiger Paketname oder ein ungültiger Paket-Unterpfad-Spezifikator.
Ungültige Paketkonfiguration: Die package.json-Konfiguration ist ungültig oder enthält eine ungültige Konfiguration.
Ungültiges Paketziel: Package-Exporte oder -Importe definieren ein Zielmodul für das Paket, das ein ungültiger Typ oder ein ungültiges String-Ziel ist.
Paketpfad nicht exportiert: Package-Exporte definieren oder erlauben keinen Ziel-Unterpfad im Paket für das angegebene Modul.
Package-Import nicht definiert: Package-Importe definieren den Spezifikator nicht.
Modul nicht gefunden: Das angeforderte Paket oder Modul existiert nicht.
Nicht unterstützter Verzeichnisimport: Der aufgelöste Pfad entspricht einem Verzeichnis, das kein unterstütztes Ziel für Modul-Importe ist.

Algorithmus zur Auflösungsbestimmung

ESM_RESOLVE(Spezifizierer, übergeordneteURL)

PACKAGE_RESOLVE(PaketSpezifizierer, übergeordneteURL)

PACKAGE_SELF_RESOLVE(PaketName, PaketUnterpfad, übergeordneteURL)

PACKAGE_EXPORTS_RESOLVE(PaketURL, Unterpfad, Exporte, Bedingungen)

PACKAGE_IMPORTS_RESOLVE(Spezifizierer, übergeordneteURL, Bedingungen)

PACKAGE_IMPORTS_EXPORTS_RESOLVE(Übereinstimmungsschlüssel, Übereinstimmungsobjekt, PaketURL, istImporte, Bedingungen)

PATTERN_KEY_COMPARE(SchlüsselA, SchlüsselB)

PACKAGE_TARGET_RESOLVE(PaketURL, Ziel, Musterübereinstimmung, istImporte, Bedingungen)

ESM_FILE_FORMAT(URL)

LOOKUP_PACKAGE_SCOPE(URL)

READ_PACKAGE_JSON(PaketURL)

DETECT_MODULE_SYNTAX(Quelle)

Anpassung des ESM-Spezifizierer-Auflösungsalgorithmus

Module-Anpassungshandler bieten einen Mechanismus zur Anpassung des ESM-Spezifizierer-Auflösungsalgorithmus. Ein Beispiel, das CommonJS-artige Auflösung für ESM-Spezifizierer bereitstellt, ist commonjs-extension-resolution-loader.

Module: ECMAScript-Module ​

Einführung ​

Aktivieren ​

Packages ​

import-Spezifizierer ​

Terminologie ​

Obligatorische Dateierweiterungen ​

URLs ​

file:-URLs ​

data:-Importe ​

node:-Importe ​

Importattribute ​

Integrierte Module ​

import()-Ausdrücke ​

import.meta ​

import.meta.dirname ​

import.meta.filename ​

import.meta.url ​

import.meta.resolve(specifier) ​

Interoperabilität mit CommonJS ​

import-Anweisungen ​

require ​

CommonJS-Namespaces ​

Unterschiede zwischen ES-Modulen und CommonJS ​

Kein require, exports oder module.exports ​

Kein __filename oder __dirname ​

Kein Addon-Laden ​

Kein require.resolve ​

Kein NODE_PATH ​

Kein require.extensions ​

Kein require.cache ​

JSON-Module ​

Wasm-Module ​

Top-Level await ​

Loader ​

Auflösungs- und Ladealgorithmus ​

Eigenschaften ​

Auflösungsalgorithmus ​

Algorithmus zur Auflösungsbestimmung ​

Anpassung des ESM-Spezifizierer-Auflösungsalgorithmus ​

Module: ECMAScript-Module

Einführung

Aktivieren

Packages

`import`-Spezifizierer

Terminologie

Obligatorische Dateierweiterungen

URLs

`file:`-URLs

`data:`-Importe

`node:`-Importe

Importattribute

Integrierte Module

`import()`-Ausdrücke

`import.meta`

`import.meta.dirname`

`import.meta.filename`

`import.meta.url`

`import.meta.resolve(specifier)`

Interoperabilität mit CommonJS

`import`-Anweisungen

`require`

CommonJS-Namespaces

Unterschiede zwischen ES-Modulen und CommonJS

Kein `require`, `exports` oder `module.exports`

Kein `filename` oder `dirname`

Kein Addon-Laden

Kein `require.resolve`

Kein `NODE_PATH`

Kein `require.extensions`

Kein `require.cache`

JSON-Module

Wasm-Module

Top-Level `await`

Loader

Auflösungs- und Ladealgorithmus

Eigenschaften

Auflösungsalgorithmus

Algorithmus zur Auflösungsbestimmung

Anpassung des ESM-Spezifizierer-Auflösungsalgorithmus