Moduldeklaration im TS

Hier lernen wir, wie man eine hochwertige Typescript-Deklarationsdatei schreibt. Sie programmieren also in ReactJS und möchten eine SVG-Datei importieren, aber Ihre IDE/tsc beschwert sich.

[ts] cannot find module './logo.svg'

Jetzt ist es an der Zeit, sich für eine schnelle Copy-Paste-Lösung an Stackoverflow zu wenden.

Aber lassen Sie uns einen Moment warten und versuchen, diese Dateien und ihre Wirkung für uns zu verstehen.

Was ist ein Modul?

In TS/JS hatten wir viele Ansätze zur Modularisierung unserer in TS/JS geschriebenen Apps. Derzeit herrscht ESM (auch bekannt als ES-Module, ES6-Module) an erster Stelle. Wir kennen sie normalerweise mit ihrer Syntax:

Um die ursprüngliche Frage zu beantworten, gilt in TS/JS in Übereinstimmung mit ECMAScript 2015 jede Datei, die einen Top-Level-Import oder -Export enthält, als Modul.

Und wenn man keinen Import oder Export auf oberster Ebene hat:

1. Sie sind überall erhältlich.
2. Sie werden als Skripte behandelt.

Warum Module verwenden?

Keine globale Namensraumverschmutzung mehr. Dies impliziert Folgendes:

1. Module werden in ihrem eigenen Bereich ausgeführt.
2. Wir müssen explizit alles exportieren, was wir exportieren wollten.
3. Der Verbraucher kann aus einem anderen Modul importieren, was er anderen zugänglich gemacht hat.

Benannte Exporte und Standardexporte

Modulauflösung

Im TS-Modul ist Auflösung der Prozess, bei dem eine Zeichenfolge aus der Import- oder Require-Anweisung entnommen und ermittelt wird, auf welche Datei sich diese Zeichenfolge bezieht.

Bei TS haben wir zwei Strategien:

1. Klassisch:
   • Die Standardeinstellung.
   • Das „compilerOptions.module“ ist nicht „CommonJS“.
   • Aus Gründen der Abwärtskompatibilität enthalten.
2. Knoten:
   • Repliziert die Funktionsweise von NodeJS im CommonJS-Modus.
   • Zusätzliche Prüfungen für .ts- und .d.ts-Dateien.

Übrigens gibt es unzählige Stellen, an denen wir es absichtlich oder unabsichtlich ändern könnten (moduleResolution, baseUrl, paths, rootDirs).

moduleResolution

• Steuert, wie TS Modulspezifizierer (diese Zeichenfolgenliterale in Import-/Export-/Require-Anweisungen) in Dateien auf der Festplatte auflöst.
• Sollte so eingestellt werden, dass er mit dem Modul-Resolver übereinstimmt, der von der Ziellaufzeit oder dem Ziel-Bundler verwendet wird.

Wenn Sie beispielsweise Ihre App für die Verwendung von ESM erstellen (die kompilierte Version verwendet ESM), müssen Sie in Ihrem CompilerOptions.module „NodeNext“ auswählen.

• Solange wir eine relative Pfaddateierweiterung verwenden, kann TS diese auflösen (z. B. {} aus „./a.js“ importieren; // ✅ Funktioniert in jeder Modulauflösung).
• Wenn Sie planen, Ihre App für die Verwendung von ESM zu kompilieren, müssen Sie die Erweiterung der Dateien angeben und können nicht ohne Erweiterung vorgehen (z. B. {} aus „a.mjs“ importieren;).
• Sie können auch ein Verzeichnis importieren, von dem erwartet wird, dass es eine index.ts-Datei enthält.

Hinweis: Wenn sich in diesem Verzeichnis eine package.json befindet. Dann verwendet TS seine Haupt- und Typen, um seine Typen zu erfassen.

Erfahren Sie hier mehr.

Wege

Grundsätzlich ordnet es Importe also dem Suchort*s* relativ zur baseUrl zu, sofern diese festgelegt ist, andernfalls zur tsconfig-Datei. Der häufigste Anwendungsfall hierfür sind Pfadaliase:

[ts] cannot find module './logo.svg'

Vorsicht

Für die Laufzeit bedeutet das nichts. Das heißt, Ihr lieber Bundler oder Compiler muss sich darum kümmern, sie richtig zu bündeln. Und wenn Ihr Pfad auf einen Ort verweist, der nicht existiert, stürzt Ihre App ab, wenn sie von NodeJS ausgeführt wird.

Tipp

Stattdessen können Sie die Importe von package.json (auch Subpath-Importe genannt) verwenden.

baseUrl

• Basisverzeichnis, aus dem der bloße Spezifizierer aufgelöst werden soll¹Modulnamen
• Hat eine höhere Priorität als Suchvorgänge von node_modules.
• Muss bei der Verwendung von Pfaden nicht mehr festgelegt werden.

rootDirs

• Viele „virtuelle“ Verzeichnisse fungieren als einzelnes Stammverzeichnis.
• Dann kann der Compiler relative Modulimporte innerhalb dieser „virtuellen“ Verzeichnisse auflösen, als ob sie in einem Verzeichnis zusammengeführt würden.

Kompiliertes JS

Um die ausgegebene JS-Ausgabe zu beeinflussen, können wir Folgendes ändern:

• compilerOptions.target:
  • Bestimmt, welche JS-Funktionen zur Ausführung in älteren JavaScript-Laufzeiten konvertiert werden.
  • Abhängig von unseren Anwendungsanforderungen, beispielsweise auf welchem ​​Browser/NodeJS/Electron ich diesen kompilierten TS-Code ausführen werde.
• compilerOptions.module:
  • Welches Modul soll die Systemlaufzeit verwenden?
  • Verwenden Sie „nodenext“ für moderne NodeJS-Projekte. Es liest die nächstgelegene package.json-Datei und entscheidet anhand ihres „type“-Werts, ob es sich für CommonJS oder ESM entscheiden soll.
  • Verwenden Sie „esnext“, wenn Sie es mit einem Bundler bündeln möchten.

Zurück zum Hauptthema

Wir möchten also eine .graphql-Datei oder eine andere Erweiterung importieren, von der TS keine Ahnung hat, wie sie aussieht (ihre Typen können nicht aufgelöst werden). Jetzt weiß TS also, wie eine importierte SVG-, GraphQL- oder andere Datei aussehen wird.

---

ref.

---

---

1. Nackter Bezeichner: ein Modulname in einer Importanweisung, der KEIN ​​ein relativer oder absoluter Pfad ist. Dies sind typischerweise Namen von Paketen in den node_modules Ihres Projekts oder anderen konfigurierten Speicherorten. ↩

Das obige ist der detaillierte Inhalt vonModuldeklaration im TS. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!