Es gibt einfache Möglichkeiten, TypeScript zu konfigurieren, um das Kompilieren und Bearbeiten zu beschleunigen. Und je früher sie implementiert werden, desto besser. Es gibt auch einige beliebte Ansätze zur Untersuchung der Ursachen für langsames Kompilieren und Bearbeiten, einige Korrekturen und allgemeine Methoden, um das TypeScript-Team bei der Behebung von Problemen zu unterstützen.

1. Schreiben von einfach zu kompilierendem Code

1.1. Schnittstellen gegenüber Kreuzungen bevorzugen (Kreuzung)

Meistens verhält sich ein einfacher Alias für einen Objekttyp wie eine Schnittstelle.

interface Foo { prop: string }

type Bar = { prop: string };

Wenn Sie jedoch eine Kombination aus zwei oder mehr Typen benötigen, können Sie diese entweder über eine Schnittstelle erweitern oder eine Schnittmenge von Typen innerhalb eines Alias erstellen. Der Unterschied zwischen diesen Ansätzen ist wichtig.

Schnittstellen erstellen einen einzelnen abgeflachten Objekttyp, der Eigenschaftskonflikte aufdeckt, deren Lösung normalerweise wichtig ist! Und Schnittpunkte kombinieren Eigenschaften nur rekursiv und generieren in einigen Fällen never

. Außerdem werden Schnittstellen besser gerendert, während Typ-Aliase für Schnittpunkte in anderen Schnittpunkten nicht angezeigt werden können. Typbeziehungen zwischen Schnittstellen werden im Gegensatz zu Schnittpunkttypen zwischengespeichert. Der letzte wichtige Unterschied besteht darin, dass bei der Validierung anhand des Zielkreuzungstyps jede Komponente validiert wird, bevor sie validiert / abgeflacht wird.

Daher wird empfohlen, Typen mit interface

/ zu erweitern, extends

anstatt Typschnittpunkte zu erstellen.

- type Foo = Bar & Baz & {
-     someProp: string;
- }
+ interface Foo extends Bar, Baz {
+     someProp: string;
+ }

1.2. Verwenden von Typanmerkungen

Das Hinzufügen von Typanmerkungen, insbesondere für Rückgabewerte, kann dem Compiler viel Arbeit ersparen. Dies liegt zum Teil daran, dass benannte Typen normalerweise kompakter sind als anonyme Typen (die der Compiler umwandeln kann), wodurch sich die Zeit zum Lesen und Schreiben von Deklarationsdateien verringert (z. B. für inkrementelle Builds). Das Casting ist sehr praktisch, so dass es nicht universell erforderlich ist. Es kann jedoch nützlich sein, es zu versuchen, wenn Sie langsame Abschnitte in Ihrem Code finden.

- import { otherFunc } from "other";
+ import { otherFunc, otherType } from "other";

- export function func() {
+ export function func(): otherType {
      return otherFunc();
  }

1.3. Bevorzugung von Basistypen gegenüber mehreren Typen

Mehrere Typen sind ein großartiges Werkzeug: Mit ihnen können Sie den Bereich möglicher Werte für einen Typ ausdrücken.

interface WeekdaySchedule {
  day: "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday";
  wake: Time;
  startWork: Time;
  endWork: Time;
  sleep: Time;
}

interface WeekendSchedule {
  day: "Saturday" | "Sunday";
  wake: Time;
  familyMeal: Time;
  sleep: Time;
}

declare function printSchedule(schedule: WeekdaySchedule | WeekendSchedule);

Aber alles hat einen Preis. Jedes Mal, wenn ein Argument an printSchedule

es übergeben wird, muss es mit jedem Element der Menge verglichen werden. Dies ist für zwei Elemente kein Problem. Wenn das Set jedoch ein Dutzend Elemente enthält, kann dies die Kompilierungsgeschwindigkeit verlangsamen. Um beispielsweise redundante Elemente zu entfernen, müssen sie alle paarweise verglichen werden. Dies ist eine quadratische Funktion. Solche Überprüfungen können auftreten, wenn große Mengen geschnitten werden, wenn die Schnittmenge für jedes Element der Menge zu großen Typen führen kann, die reduziert werden müssen. Und Sie können all dies vermeiden, indem Sie Untertypen und keine Mengen verwenden.

interface Schedule {
  day: "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday" | "Saturday" | "Sunday";
  wake: Time;
  sleep: Time;
}

interface WeekdaySchedule extends Schedule {
  day: "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday";
  startWork: Time;
  endWork: Time;
}

interface WeekendSchedule extends Schedule {
  day: "Saturday" | "Sunday";
  familyMeal: Time;
}

declare function printSchedule(schedule: Schedule);

Ein realistischeres Beispiel ist der Versuch, alle integrierten DOM-Elementtypen zu modellieren. In diesem Fall ist es vorzuziehen, einen Basistyp HtmlElement

mit häufigen Elementen zu erstellen , der mit usw. erweitert DivElement

wird ImgElement

, anstatt eine schwere Menge zu erstellen DivElement | /*...*/ | ImgElement | /*...*/

.

2. Verwenden von Projektlinks

Wenn Sie eine große TypeScript-Codebasis erstellen, ist es hilfreich, diese in mehreren unabhängigen Projekten zu organisieren . Jeder von ihnen hat seine eigenen tsconfig.json

mit Abhängigkeiten in anderen Projekten. Dies kann dazu beitragen, das Herunterladen zu vieler Dateien auf einmal zu vermeiden, und es kann auch das Mischen und Anpassen verschiedener Codebasisschemata erleichtern.

Es gibt einige sehr einfache Möglichkeiten, Ihre Codebasis in Projekte aufzuteilen . Zum Beispiel ein Projekt für einen Client, ein Projekt für einen Server und ein gemeinsames Projekt zwischen ihnen.

             ------------
              |          |
              |  Shared  |
              ^----------^
             /            \
            /              \
------------                ------------
|          |                |          |
|  Client  |                |  Server  |
-----^------                ------^-----

Tests können auch in ein separates Projekt unterteilt werden.

             ------------
              |          |
              |  Shared  |
              ^-----^----^
             /      |     \
            /       |      \
------------  ------------  ------------
|          |  |  Shared  |  |          |
|  Client  |  |  Tests   |  |  Server  |
-----^------  ------------  ------^-----
     |                            |
     |                            |
------------                ------------
|  Client  |                |  Server  |
|  Tests   |                |  Tests   |
------------                ------------

Die Leute fragen oft: "Wie groß sollte das Projekt sein?" Es ist wie zu fragen: "Wie groß sollte eine Funktion sein?" oder "Wie groß sollte die Klasse sein?" Viel hängt von der Erfahrung ab. Angenommen, Sie können JS / TS-Code mithilfe von Ordnern freigeben. Wenn einige Komponenten so miteinander verbunden sind, dass sie in einem Ordner gespeichert werden können, können Sie davon ausgehen, dass sie zum selben Projekt gehören. Vermeiden Sie auch große oder kleine Projekte. Wenn einer von ihnen größer ist als alle anderen zusammen, ist dies ein schlechtes Zeichen. Es ist auch am besten, nicht Dutzende von Einzeldateiprojekten zu erstellen, da dies den Overhead erhöht.

Über projektübergreifende Links können Sie hier lesen .

3. Konfigurieren von tsconfig.json oder jsconfig.json

TypeScript- und JavaScript-Benutzer können ihre Kompilierungen jederzeit mithilfe der Datei tsconfig.json anpassen. Jsconfig.json-Dateien können auch zum Anpassen der JavaScript- Bearbeitung verwendet werden .

3.1. Dateien definieren

Stellen Sie immer sicher, dass in Ihren Konfigurationsdateien nicht zu viele Dateien gleichzeitig aufgelistet sind.

Sie tsconfig.json

können Projektdateien auf zwei Arten definieren:

Liste files

;
Listen include

und exclude

;

Der Hauptunterschied zwischen den beiden besteht darin, dass files

eine Liste der Quelldateipfade abgerufen wird und include

/ exclude

mithilfe von Globbing-Mustern die entsprechenden Dateien identifiziert werden.

Durch die Definition files

ermöglichen wir TypeScript, Dateien schnell und direkt zu laden. Dies kann umständlich sein, wenn das Projekt viele Dateien und nur wenige übergeordnete Einstiegspunkte enthält. Es ist auch leicht zu vergessen, neue Dateien hinzuzufügen tsconfig.json

, und dann werden Sie auf ein seltsames Editorverhalten stoßen.

include

/ exclude

erfordert nicht, dass alle diese Dateien identifiziert werden, aber das System sollte sie erkennen, indem es die hinzugefügten Verzeichnisse durchläuft. Und wenn es viele davon gibt , kann sich die Kompilierung verlangsamen. Darüber hinaus enthält die Zusammenstellung manchmal zahlreiche unnötige.d.ts

und Testdateien, die auch die Geschwindigkeit verringern und den Speicherverbrauch erhöhen können. Während exclude

es in einigen Konfigurationen, wie z. B. Mono-Repositorys, geeignete Standardeinstellungen gibt node_modules

, werden solche "schweren" Ordner zur Kompilierungszeit hinzugefügt.

Am besten machen Sie das:

Definieren Sie nur die Eingabeordner Ihres Projekts (z. B. den Quellcode, aus dem Sie während der Kompilierung und Analyse hinzufügen möchten).
Mischen Sie keine Quelldateien aus verschiedenen Projekten im selben Ordner.
Wenn Sie Tests im selben Quellordner speichern, benennen Sie sie, damit sie leicht ausgeschlossen werden können.
Vermeiden Sie das Erstellen großer Assembly-Artefakte und Abhängigkeitsordner wie node_modules

.

Hinweis: Ohne Liste wird der exclude

Ordner node_modules

standardmäßig ausgeschlossen. Und wenn die Liste hinzugefügt wird, ist es wichtig, sie explizit anzugeben node_modules

.

Hier ist ein Beispiel tsconfig.json

:

{
    "compilerOptions": {
        // ...
    },
    "include": ["src"],
    "exclude": ["**/node_modules", "**/.*/"],
}

3.2. Kontrolle über das Hinzufügen von @types

Standardmäßig fügt TypeScript automatisch alle gefundenen node_modules

Pakete in einem Ordner hinzu @types

, unabhängig davon, ob Sie sie importiert haben oder nicht. Dies dient dazu, dass bestimmte Funktionen bei Verwendung von Node.js, Jasmine, Mocha, Chai usw. „nur funktionieren“, da diese Tools / Pakete nicht importiert, sondern in die globale Umgebung geladen werden.

Manchmal kann diese Logik das Kompilieren und Bearbeiten des Programms verlangsamen. Und führen sogar zu Deklarationskonflikten in zahlreichen globalen Paketen, die Fehler wie diesen verursachen:

Duplicate identifier 'IteratorResult'.
Duplicate identifier 'it'.
Duplicate identifier 'define'.
Duplicate identifier 'require'.

Wenn keine globalen Pakete benötigt werden, können Sie in der Option "types" in tsconfig.json

/ jsconfig.json

: einen leeren Ordner definieren.

// src/tsconfig.json
{
   "compilerOptions": {
       // ...

       // Don't automatically include anything.
       // Only include `@types` packages that we need to import.
       "types" : []
   },
   "files": ["foo.ts"]
}

Wenn Sie globale Pakete benötigen, fügen Sie diese dem Feld hinzu types

.

// tests/tsconfig.json
{
   "compilerOptions": {
       // ...

       // Only include `@types/node` and `@types/mocha`.
       "types" : ["node", "mocha"]
   },
   "files": ["foo.test.ts"]
}

3.3. Inkrementelle Projekterstellung

Mit dem Flag --incremental

kann TypeScript den zuletzt kompilierten Status in einer Datei speichern .tsbuildinfo

. Es wird verwendet, um die Mindestmenge an Dateien zu definieren, die seit dem letzten Lauf erneut überprüft / überschrieben werden können, wie z. B. der Modus --watch

in TypeScript.

Die inkrementelle Generierung ist standardmäßig aktiviert, wenn das composite

projektübergreifende Referenzflag verwendet wird. Sie kann jedoch auch jedes andere Projekt beschleunigen.

3.4. Validierung überspringen .d.ts

Standardmäßig überprüft TypeScript alle .d.ts

Dateien in einem Projekt vollständig auf Probleme und Inkonsistenzen. Dies wird aber normalerweise nicht benötigt. Meistens ist bekannt, dass diese Dateien bereits funktionieren: Die Methoden zur Typerweiterung wurden bereits überprüft, wichtige Deklarationen werden jedoch weiterhin überprüft.

Mit TypeScript kann ein Flag skipDefaultLibCheck

die Typprüfung in bereitgestellten .d.ts

Dateien überspringen (z. B. in lib.d.ts

).

Sie können das Flag auch aktivieren skipLibCheck

, um die Überprüfung aller .d.ts

Dateien in der Kompilierung zu überspringen .

Diese beiden Optionen verbergen häufig Konfigurationsfehler und .d.ts

Dateikonflikte. Es wird daher empfohlen, sie nur zu verwenden, um den Build zu beschleunigen.

3.5. Schnellere Variadikprüfungen

Liste der Hunde oder Tiere? Können Sie führen List<Dg>

zu List<Animls>

? Eine einfache Möglichkeit, die Antwort zu finden, besteht darin, die Typen Element für Element strukturell zu vergleichen. Leider kann diese Lösung sehr teuer sein. Aber wenn wir genug kennen List<>

, dann können wir Zuordnung Kontrollen reduzieren zu ermitteln , ob es zulässig ist , beziehen Dog

auf Animal

(das heißt, ohne jedes Element überprüft List<>

). Insbesondere müssen wir die Variabilität des Parametertyps kennen T

. Der Compiler kann die Optimierung nur dann voll ausnutzen, wenn das Flag aktiviert ist strictFunctionTypes

(andernfalls wird eine langsamere, aber mildere Strukturprüfung verwendet). Daher wird empfohlen, mit dem Flag zu erstellen --strictFunctionTypes

(das standardmäßig unter aktiviert ist --strict

).

4. Andere Montagewerkzeuge einrichten

TypeScript wird häufig mit anderen Erstellungstools kompiliert, insbesondere beim Erstellen einer Webanwendung, die Bundler verwenden kann. Wir können nur einige Ideen anbieten, aber im Allgemeinen kann dieser Ansatz verallgemeinert werden.

Lesen Sie zusätzlich zu diesem Teil unbedingt die Leistung des von Ihnen ausgewählten Tools, zum Beispiel:

4.1. Gleichzeitige Typprüfung

Die Typprüfung erfordert normalerweise Informationen aus anderen Dateien und ist im Vergleich zu anderen Schritten wie dem Konvertieren / Schreiben von Code relativ teuer. Da die Typprüfung sehr zeitaufwändig sein kann, kann sie den internen Entwicklungszyklus beeinflussen. Das heißt, der Zyklus zum Bearbeiten, Kompilieren und Ausführen wird länger, was unangenehm ist.

Daher können viele Build-Tools Typen in einem separaten Prozess überprüfen, ohne die Dateierstellung zu blockieren. In diesem Fall wird möglicherweise fehlerhafter Code ausgeführt, bevor TypeScript den Fehler in Ihrem Build-Tool meldet. Meistens werden zuerst Fehler im Editor angezeigt und es wird nicht darauf gewartet, dass der Code ausgeführt wird.

Ein Beispiel ist das fork-ts-checker-webpack-Plugin für Webpack oder ähnlichesawesome-Typoskript-Lader .

4.2. Isolierte Dateierstellung

Standardmäßig erfordert das Erstellen von Dateien in TypeScript semantische Informationen, die möglicherweise nicht lokal für die Datei sind. Dies ist notwendig, um zu verstehen, wie Features mögen const enum

und generiert werden namespace

. Manchmal wird die Generierung jedoch langsamer, da andere Dateien überprüft werden müssen, um das Ergebnis für eine beliebige Datei zu generieren.

Wir benötigen selten Funktionen, die nicht lokale Informationen erfordern. enum

Stattdessen können Stammgäste und stattdessen const enum

Module verwendet werden namespace

. Daher verfügt TypeScript über ein Flag isolatedModules

zum Auslösen von Fehlern bei Funktionen, für die nicht lokale Informationen erforderlich sind. Mit diesem Flag können Sie sicher Tools verwenden, die TypeScript-APIs wie transpileModule

oder alternative Compiler wie Babel verwenden.

Dieser Code funktioniert zur Laufzeit bei der Konvertierung von Sandbox-Dateien nicht ordnungsgemäß, da die Werte inline sein müssen const enum

. Zum Glück wird er isolatedModules

uns im Voraus warnen.

// ./src/fileA.ts

export declare const enum E {
    A = 0,
    B = 1,
}

// ./src/fileB.ts

import { E } from "./fileA";

console.log(E.A);
//          ~
// error: Cannot access ambient const enums when the '--isolatedModules' flag is provided.

Denken Sie daran: isolatedModules

Beschleunigt die Codegenerierung nicht automatisch. Es wird nur vor der Verwendung einer Funktion gewarnt, die möglicherweise nicht unterstützt wird. Sie müssen Module isoliert in verschiedenen Build-Tools und APIs generieren.

Sie können Dateien isoliert mit den folgenden Tools erstellen:

Der ts-loader verfügt über ein Flag transpileOnly , das isolierte Erstellungsdateien mit bereitstellt transpileModule

.
awesome-typescript-loader transpileOnly, transpileModule

.
API transpileModule TypeScript .
awesome-typescript-loader useBabel.
babel-loader ( ).
gulp-typescript isolatedModules

.
rollup-plugin-typescript .
ts-jest [ isolatedModules

true

].
ts-node kann die Option "transpileOnly" im Feld "ts-node" der Datei tsconfig.json definieren und verfügt außerdem über das Flag --transpile-only .

5. Problemuntersuchung

Es gibt verschiedene Möglichkeiten, um herauszufinden, warum etwas schief geht.

5.1. Editor-Plugins deaktivieren

Plugins können die Funktionsweise des Editors beeinflussen. Deaktivieren Sie sie (insbesondere JavaScript / TypeScript) und prüfen Sie, ob sich Leistung und Reaktionsfähigkeit verbessern.

Einige Redakteure haben ihre eigenen Leistungsempfehlungen. Lesen Sie diese. Beispielsweise verfügt Visual Studio Code über eine separate Seite mit Tipps .

5.2. erweiterteDiagnostik

Sie können TypeScript mit ausführen, um --extendedDiagnostics

zu sehen, wo die Zeit des Compilers verbracht wird:

Files:                         6
Lines:                     24906
Nodes:                    112200
Identifiers:               41097
Symbols:                   27972
Types:                      8298
Memory used:              77984K
Assignability cache size:  33123
Identity cache size:           2
Subtype cache size:            0
I/O Read time:             0.01s
Parse time:                0.44s
Program time:              0.45s
Bind time:                 0.21s
Check time:                1.07s
transformTime time:        0.01s
commentTime time:          0.00s
I/O Write time:            0.00s
printTime time:            0.01s
Emit time:                 0.01s
Total time:                1.75s

Bitte beachten Sie, dass Total time

dies nicht die Summe aller aufgeführten Zeitkosten ist, da sich einige davon überschneiden und andere überhaupt nicht gemessen werden.

Die relevantesten Informationen für die meisten Benutzer:

Feld	Wert
`Files`	Die Anzahl der im Programm enthaltenen Dateien (welche Art von Dateien können Sie verwenden `--listFiles` ).
`I/O Read time`	Zeitaufwand für das Lesen aus dem Dateisystem. Dies beinhaltet das Lesen von Ordnern aus `include` .
`Parse time`	Zeitaufwand für das Scannen und Parsen des Programms.
`Program time`	Die Gesamtzeit zum Lesen aus dem Dateisystem, zum Scannen und Parsen des Programms sowie für andere Diagrammberechnungen. Diese Stufen werden hier kombiniert, da sie aktiviert und geladen werden müssen, sobald sie über `import` und hinzugefügt werden `export` .
`Bind time`	Zeitaufwand für das Zusammenstellen verschiedener semantischer Informationen, die für eine bestimmte Datei lokal sind.
`Check time`	Die Zeit, die für die Überprüfung der Typen im Programm aufgewendet wurde.
`transformTime time`	Zeitaufwand für das Umschreiben von TypeScript-ASTs (Bäume, die Quelldateien darstellen) in Formulare, die in älteren Laufzeitumgebungen funktionieren.
`commentTime`	Zeitaufwand für die Auswertung von Kommentaren in generierten Dateien.
`I/O Write time`	Zeitaufwand für das Schreiben und Aktualisieren von Dateien auf der Festplatte.
`printTime`	Zeitaufwand für die Berechnung der Zeichenfolgendarstellung der generierten Datei und deren Speicherung auf der Festplatte.

Angesichts dieser Eingaben benötigen Sie möglicherweise Folgendes:

Entspricht die Anzahl der Dateien / Codezeilen ungefähr der Anzahl der Dateien im Projekt? Wenn nicht, versuchen Sie es mit --listFiles

.
Werte Program time

oder I/O Read time

groß aussehen? Überprüfen Sie, ob die Einstellungen korrekt sind include

/exclude

Sieht so aus, als ob mit anderen Timings etwas nicht stimmt? Sie können einen Problembericht ausfüllen! Was hilft Ihnen bei der Diagnose:

Beginnen Sie mit, emitDeclarationOnly

wenn der Wert printTime

hoch ist.
Anweisungen zum Melden von Compiler-Leistungsproblemen

5.3. showConfig

Es ist nicht immer klar, mit welchen Einstellungen die Kompilierung beim Start durchgeführt wird tsc

, insbesondere wenn man bedenkt, dass tsconfig.jsons

andere Konfigurationsdateien erweitert werden können. showConfig

kann erklären, was es berechnen wird tsc

.

tsc --showConfig

# or to select a specific config file...

tsc --showConfig -p tsconfig.json

5.4. traceResolution

Wenn Sie mit traceResolution

ausführen, erfahren Sie, warum die Datei zur Kompilierung hinzugefügt wurde. Die Daten sind sehr umfangreich, sodass Sie das Ergebnis in einer Datei speichern können:

tsc --traceResolution > resolution.txt

Wenn Sie eine Datei , die nicht da sein sollte, können Sie die Liste korrigieren include

/ exclude

in der Datei tsconfig.json

, oder die Einstellungen anpassen , wie types

, typeRoots

oder paths

.

5.5. Ein tsc ausführen

Benutzer haben häufig eine schlechte Leistung mit Build-Tools von Drittanbietern wie Gulp, Rollup, Webpack usw. Wenn Sie tsc --extendedDiagnostics

nach größeren Abweichungen zwischen TypeScript und einem Tool von Drittanbietern suchen, kann dies auf Fehler in externen Konfigurationen oder Ineffizienz hinweisen.

Was Sie sich fragen müssen:

Gibt es einen großen Unterschied in den Erstellungszeiten tsc

mit dem integrierten TypeScript-Tool?
Wenn das Drittanbieter-Tool über Diagnosetools verfügt, unterscheidet sich die Lösung zwischen TypeScript und dem Drittanbieter-Tool?
Verfügt das Tool über eine eigene Konfiguration , die möglicherweise zu einer schlechten Leistung führt?
Verfügt das Tool über eine Konfiguration zur Integration in TypeScript , die möglicherweise zu einer schlechten Leistung führt (z. B. Optionen für ts-loader)?

5.6. Abhängigkeiten aktualisieren

Manchmal können rechnerisch komplexe Dateien die Typprüfung in TypeScript beeinflussen .d.ts

. Selten, aber es passiert. Dies wird normalerweise durch ein Upgrade auf eine neuere Version von TypeScript (effizienter) oder eine neuere Version des Pakets @types

(die die Regression umkehren könnte) behoben .

6. Häufige Probleme

Wenn Sie mit Schwierigkeiten konfrontiert sind, sollten Sie sich über Lösungen für häufig auftretende Probleme informieren. Wenn das Folgende nicht hilft, können Sie das Problem melden .

6.1. Falsch konfiguriertes Ein- und Ausschließen

Wie bereits erwähnt, können die Optionen include

/ exclude

missbraucht werden.

Problem	Ursache	Korrektur
`node_modules` wurde versehentlich aus einem tieferen Unterordner hinzugefügt.	Wurde nicht konfiguriert `exclude`	`"exclude": ["/node_modules", "/.*/"]`
`node_modules` wurde versehentlich aus einem tieferen Unterordner hinzugefügt.	`"exclude": ["node_modules"]`	`"exclude": ["/node_modules", "/.*/"]`
Versteckte Dateien mit einem Punkt werden zufällig hinzugefügt (zum Beispiel `.git` ).	`"exclude": ["**/node_modules"]`	`"exclude": ["/node_modules", "/.*/"]`
Unerwartete Dateien hinzugefügt.	Wurde nicht konfiguriert `include`	`"include": ["src"]`

7. Ausfüllen von Problemberichten

Wenn Ihr Projekt bereits korrekt und optimal konfiguriert ist, können Sie einen Problembericht ausfüllen .

Ein guter Bericht enthält eine leicht verständliche Beschreibung des Problems. Das heißt, es enthält eine Codebasis aus mehreren Dateien, die einfach über Git geklont werden können. In diesem Fall ist keine externe Integration in Assembly-Tools erforderlich. Sie können aufgerufen werden tsc

, oder Sie können Sandbox-Code verwenden, der die TypeScript-API verwendet. Sie können keine Codebasen priorisieren, die komplexe Aufrufe und Einstellungen erfordern.

Ja, das ist nicht immer leicht zu erreichen. Insbesondere, weil es schwierig ist, die Ursache des Problems innerhalb der Codebasis zu isolieren, und es gibt auch Überlegungen zum Schutz des geistigen Eigentums. In einigen Fällen können Sie uns eine NDA senden, wenn Sie der Meinung sind, dass das Problem von großer Bedeutung ist.

Unabhängig von der Reproduzierbarkeit des Problems befolgen Sie beim Ausfüllen des Berichts diese Tipps. Sie helfen uns bei der Suche nach einer Lösung.

7.1. Bericht über Compiler-Leistungsprobleme

Gelegentlich treten Leistungsprobleme sowohl beim Erstellen als auch beim Bearbeiten auf. Dann ist es sinnvoll, sich auf den TypeScript-Compiler zu konzentrieren.

Verwenden Sie zunächst die "nächtliche" Version von TypeScript, um sicherzustellen, dass Sie nicht auf ein behobenes Problem stoßen:

npm install --save-dev typescript@next

# or

yarn add typescript@next --dev

Die Beschreibung des Leistungsproblems sollte Folgendes enthalten:

Installierte Version von TypeScript ( npx tsc -v

oder yarn tsc -v

).
Die Version von Node, auf der TypeScript ( node -v

) ausgeführt wurde .
Ergebnis der Ausführung mit Option extendedDiagnostics

( tsc --extendedDiagnostics -p tsconfig.json

).
Idealerweise wird das Projekt selbst benötigt, um das vorliegende Problem zu demonstrieren.
Compiler-Profiler-Protokoll (Dateien isolate-*-*-*.log

und *.cpuprofile

).

Compiler-Profilerstellung

Es ist wichtig, dass Sie einen Diagnose-Trace bereitstellen, indem Sie Node.js v10 + mit dem Flag --trace-ic

und TypeScript mit dem Flag ausführen --generateCpuProfile

:

node --trace-ic ./node_modules/typescript/lib/tsc.js --generateCpuProfile profile.cpuprofile -p tsconfig.json

Dies ./node_modules/typescript/lib/tsc.js

kann durch den Pfad ersetzt werden, in dem Ihre Version des TypeScript-Compilers installiert ist. Stattdessen tsconfig.json

kann es sich um eine beliebige TypeScript-Konfigurationsdatei handeln. Stattdessen profile.cpuprofile

- die Ausgabedatei Ihrer Wahl.

Es werden zwei Dateien generiert:

--trace-ic

speichert die Daten in einer Ansichtsdatei isolate-*-*-*.log

(zum Beispiel isolate-00000176DB2DF130-17676-v8.log

).
--generateCpuProfile

speichert die Daten in einer Datei mit einem Namen Ihrer Wahl. Im obigen Beispiel ist dies profile.cpuprofile

.

Hinweis : Diese Dateien enthalten möglicherweise Informationen aus Ihrem Arbeitsbereich, einschließlich Pfaden und Quellcode. Beide Dateien werden im Klartext erstellt, und Sie können sie bearbeiten, bevor Sie sie an den Github-Bericht anhängen (z. B. indem Sie Pfade entfernen, die vertrauliche Informationen enthalten könnten).

Wenn Sie jedoch Zweifel daran haben, sie auf Github zu stellen, schreiben Sie uns, und Sie können die Informationen privat senden.

7.2. Leistungsprobleme des Berichtseditors

Es kann viele Gründe für eine schlechte Bearbeitungsleistung geben. Das TypeScript-Team kann nur die Leistung des JavaScript / TypeScript-Sprachdienstes sowie die Integration zwischen dem Sprachdienst und bestimmten Editoren (z. B. Visual Studio, Visual Studio-Code, Visual Studio für Mac und Sublime Text) beeinflussen. Stellen Sie sicher, dass alle Plugins von Drittanbietern in Ihrem Editor deaktiviert sind. Dadurch wird überprüft, ob das Problem mit TypeScript selbst zusammenhängt.

Die Leistungsprobleme des Editors sind etwas komplexer, aber es gelten dieselben Ideen: Klonierte minimale Codebasen mit einem reproduzierbaren Problem sind ideal. In einigen Fällen können wir eine NDA unterzeichnen, um Probleme zu untersuchen und zu isolieren.

Hinzufügen von Daten austsc --extendedDiagnostics

, aber noch besser, wenn es einen TSServer-Trace gibt.

Abrufen von TSServer-Protokollen in Visual Studio Code

Öffnen Sie die Befehlsleiste und dann:
Stellen Sie die Option ein «typescript.tsserver.log»: «verbose»,

.
Starten Sie VS Code neu und reproduzieren Sie das Problem.
Führen Sie in VS Code den Befehl aus TypeScript: Open TS Server log

.
Die Datei sollte geöffnet werden tsserver.log

.

Hinweis : Das TSServer-Protokoll enthält möglicherweise Informationen aus Ihrem Arbeitsbereich, einschließlich Pfaden und Quellcode. Wenn Sie Zweifel daran haben, es auf Github zu stellen, schreiben Sie uns und Sie können die Informationen privat senden.

TypeScript-Leistung