Il existe des moyens simples de configurer TypeScript pour accélérer la compilation et l'édition. Et plus tôt ils sont mis en œuvre, mieux c'est. Il existe également des approches populaires pour rechercher les causes de la compilation et de l'édition lentes, des correctifs et des moyens courants d'aider l'équipe TypeScript à résoudre les problèmes.

1. Rédaction de code facile à compiler

1.1. Préférence pour les interfaces sur les intersections (intersection)

Le plus souvent, un simple alias pour un type d'objet agit de la même manière qu'une interface.

interface Foo { prop: string }

type Bar = { prop: string };

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Mais si vous avez besoin d'une combinaison de deux types ou plus, vous pouvez les étendre à l'aide d'une interface ou créer une intersection de types dans un alias. La différence entre ces approches est importante.



Les interfaces créent un seul type d'objet aplati qui expose les conflits de propriété qu'il est généralement important de résoudre! Et les intersections combinent récursivement les propriétés et, dans certains cas, génèrent never



. De plus, les interfaces sont mieux rendues, tandis que les alias de type vers les intersections ne peuvent pas être affichés dans d'autres intersections. Les relations de type entre les interfaces sont mises en cache, contrairement aux types d'intersection. La dernière différence importante est que lors de la validation par rapport au type d'intersection cible, chaque composant est validé avant d'être validé / aplati.



Par conséquent, il est recommandé d'étendre les types avec interface



/ extends



plutôt que de créer des intersections de types.

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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

1.2. Utilisation des annotations de type

L'ajout d'annotations de type, en particulier pour les valeurs de retour, peut économiser beaucoup de travail au compilateur. Cela est en partie dû au fait que les types nommés sont généralement plus compacts que les types anonymes (que le compilateur peut convertir), ce qui réduit le temps nécessaire pour lire et écrire les fichiers de déclaration (par exemple, pour les versions incrémentielles). Le casting est très pratique, il n'est donc pas nécessaire de le faire universellement. Mais il peut être utile d'essayer lorsque vous trouvez des fragments lents dans votre code.

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

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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

1.3. Préférence pour les types de base sur plusieurs types

Les types multiples sont un excellent outil: ils vous permettent d'exprimer la plage de valeurs possibles pour un type.

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);

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Mais tout a un prix. Chaque fois qu'un argument lui est passé printSchedule



, il doit être comparé à chaque élément de l'ensemble. Ce n'est pas un problème pour deux éléments. Mais s'il y a une douzaine d'éléments dans l'ensemble, cela peut ralentir la vitesse de compilation. Par exemple, pour supprimer les éléments redondants, ils doivent tous être comparés par paires, c'est une fonction quadratique. De telles vérifications peuvent se produire lors de l'intersection de grands ensembles, lorsque l'intersection de chaque élément de l'ensemble peut conduire à des types énormes qui doivent être réduits. Et vous pouvez éviter tout cela en utilisant des sous-types, pas des ensembles.

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);

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Un exemple plus réaliste consiste à essayer de modéliser tous les types d'éléments DOM intégrés. Dans ce cas, il est préférable de créer un type de base HtmlElement



avec des éléments fréquents, qui se développe avec DivElement



, ImgElement



etc., plutôt que de créer un ensemble lourd DivElement | /*...*/ | ImgElement | /*...*/



.

2. Utilisation des liens de projet

Lors de la création d'une grande base de code TypeScript, il est utile de l'organiser en plusieurs projets indépendants . Chacun d'eux a ses propres tsconfig.json



dépendances dans d'autres projets. Cela peut aider à éviter de télécharger trop de fichiers en une seule compilation, et cela peut également faciliter le mélange et la correspondance de différents schémas de base de code.



Il existe des moyens très simples de diviser votre base de code en projets . Par exemple, un projet pour un client, un projet pour un serveur et un projet commun entre eux.

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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Les tests peuvent également être séparés dans un projet distinct.

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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Les gens demandent souvent: "Quelle devrait être la taille du projet?" C'est comme demander: "Quelle devrait être la taille d'une fonction?" ou "Quelle devrait être la taille de la classe?" Cela dépend beaucoup de l'expérience. Supposons que vous puissiez partager du code JS / TS à l'aide de dossiers, et si certains composants sont suffisamment interconnectés pour les placer dans un dossier, vous pouvez les considérer comme appartenant au même projet. Évitez également les grands ou petits projets. Si l'un d'eux est plus grand que tous les autres combinés, c'est un mauvais signe. Il est également préférable de ne pas créer des dizaines de projets sur un seul fichier, car cela augmente les frais généraux.



Vous pouvez en savoir plus sur les liens entre projets ici .

3. Configuration de tsconfig.json ou jsconfig.json

Les utilisateurs de TypeScript et JavaScript peuvent toujours personnaliser leurs compilations à l'aide du fichier tsconfig.json. Les fichiers Jsconfig.json peuvent également être utilisés pour personnaliser l'édition JavaScript .

3.1. Définition des fichiers

Assurez-vous toujours que vos fichiers de configuration ne répertorient pas trop de fichiers à la fois.



Vous tsconfig.json



pouvez définir les fichiers de projet de deux manières:

• liste files
  
  
  
  ;
• listes include
  
  
  
  et exclude
  
  
  
  ;

La principale différence entre les deux est qu'il files



obtient une liste de chemins de fichiers source et include



/ exclude



utilise des modèles de globulation pour identifier les fichiers correspondants.



En définissant files



, nous permettons à TypeScript de charger rapidement des fichiers directement. Cela peut être fastidieux si le projet contient de nombreux fichiers et seulement quelques points d'entrée de haut niveau. Il est également facile d'oublier d'ajouter de nouveaux fichiers tsconfig.json



, puis vous rencontrez un comportement étrange de l'éditeur.



include



/ exclude



n'exige pas que tous ces fichiers soient identifiés, mais le système doit les détecter en passant par les répertoires ajoutés. Et s'il y en a beaucoup , la compilation peut ralentir. De plus, la compilation comprend parfois de nombreux.d.ts



et les fichiers de test, qui peuvent également réduire la vitesse et augmenter la consommation de mémoire. Enfin, bien exclude



qu'il existe des valeurs par défaut appropriées, certaines configurations, comme les référentiels mono, ont des dossiers "lourds" comme ceux node_modules



qui seront ajoutés au moment de la compilation.



Il est préférable de faire ceci:

• Définissez uniquement les dossiers d'entrée de votre projet (par exemple, le code source à partir duquel vous souhaitez ajouter pendant la compilation et l'analyse).
• Ne mélangez pas les fichiers source de différents projets dans le même dossier.
• Si vous stockez les tests dans le même dossier que les sources, nommez-les de manière à ce qu'ils puissent être facilement exclus.
• Évitez de créer des artefacts d'assemblage volumineux et des dossiers de dépendances tels que node_modules
  
  
  
  .

Remarque: sans liste, le exclude



dossier node_modules



sera exclu par défaut. Et si la liste sera ajoutée, il est important de l'indiquer explicitement node_modules



.



Voici un exemple tsconfig.json



:

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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

3.2. Contrôle de l'ajout de @types

Par défaut, TypeScript ajoute automatiquement tous les node_modules



packages trouvés dans un dossier @types



, que vous les ayez importés ou non. Ceci est fait pour que certaines fonctions «fonctionnent juste» lors de l'utilisation de Node.js, Jasmine, Mocha, Chai, etc., puisque ces outils / packages ne sont pas importés, mais chargés dans l'environnement global.



Parfois, cette logique peut ralentir la compilation et l'édition du programme. Et même conduire à des conflits de déclaration dans de nombreux packages globaux qui provoquent des erreurs comme celle-ci:

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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Si les packages globaux ne sont pas nécessaires, vous pouvez définir un dossier vide dans l'option "types" dans tsconfig.json



/ jsconfig.json



:

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

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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Si vous avez besoin de packages globaux, ajoutez-les au champ types



.

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

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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

3.3. Génération incrémentale de projet

L'indicateur --incremental



permet à TypeScript d'enregistrer le dernier état compilé dans un fichier .tsbuildinfo



. Il est utilisé pour définir l'ensemble minimum de fichiers pouvant être revérifiés / écrasés depuis la dernière exécution, comme le mode --watch



dans TypeScript.



La génération incrémentielle est activée par défaut lors de l'utilisation de l'indicateur de composite



référence inter-projets, mais elle peut également accélérer tout autre projet.

3.4. Ignorer la validation .d.ts

Par défaut, TypeScript revérifiera complètement tous les .d.ts



fichiers d'un projet pour trouver les problèmes et les incohérences. Mais ce n'est généralement pas nécessaire. Le plus souvent, ces fichiers sont déjà connus pour fonctionner: les méthodes d'expansion de type ont déjà été testées, mais les déclarations importantes seront toujours vérifiées.



TypeScript permet à un indicateur d' skipDefaultLibCheck



ignorer la vérification de type dans les .d.ts



fichiers fournis (par exemple, dans lib.d.ts



).



Vous pouvez également activer l'indicateur skipLibCheck



pour ignorer la vérification de tous les .d.ts



fichiers lors de la compilation.



Ces deux options masquent souvent les erreurs de configuration et .d.ts



les conflits de fichiers, il est donc recommandé de les utiliser uniquement pour accélérer la construction.

3.5. Contrôles variadiques plus rapides

Liste des chiens ou des animaux? Pouvez-vous conduire List<Dg>



à List<Animls>



? Un moyen simple de trouver la réponse consiste à comparer structurellement les types, élément par élément. Malheureusement, cette solution peut être très coûteuse. Mais si nous en savons assez List<>



, nous pouvons réduire les contrôles d'affectation pour déterminer s'il est permis de se référer Dog



à Animal



(qui est, sans vérifier chaque élément List<>



). En particulier, nous devons connaître la variabilité du type de paramètre T



. Le compilateur ne peut tirer pleinement parti de l'optimisation que lorsque l'indicateur est activé strictFunctionTypes



(sinon, il utilisera une vérification structurelle plus lente mais plus indulgente). Par conséquent, il est recommandé de construire avec l'indicateur --strictFunctionTypes



(qui est activé par défaut sous --strict



).

4. Configuration d'autres outils d'assemblage

TypeScript est souvent compilé avec d'autres outils de création, en particulier lors de la création d'une application Web pouvant utiliser un bundler. Nous ne pouvons proposer que quelques idées, mais en général cette approche peut être généralisée.



En plus de cette partie, assurez-vous de lire sur les performances de l'outil choisi, par exemple:

• La partie ts-loader dans l'article Faster Builds .
• Une partie sur awesome-typescript-loader dans l'article sur les problèmes de performances .

4.1. Vérification de type simultanée

La vérification de type nécessite généralement des informations provenant d'autres fichiers et est relativement coûteuse par rapport à d'autres étapes telles que la conversion / l'écriture de code. Étant donné que la vérification de type peut prendre beaucoup de temps, elle peut affecter le cycle de développement interne. Autrement dit, le cycle d'édition-compilation-exécution deviendra plus long, ce qui est désagréable.



Par conséquent, de nombreux outils de construction peuvent vérifier les types dans un processus distinct, sans bloquer la création de fichiers. Bien que dans ce cas, un code erroné puisse être exécuté avant que TypeScript ne signale l'erreur dans votre outil de génération. Plus souvent qu'autrement, vous verrez d'abord des erreurs dans l'éditeur et n'attendrez pas que le code s'exécute.



Un exemple est le fork-ts-checker-webpack-plugin pour Webpack, ou similairechargeur-génial-typescript .

4.2. Création de fichiers isolés

Par défaut, la création de fichiers dans TypeScript nécessite des informations sémantiques qui peuvent ne pas être locales au fichier. Ceci est nécessaire pour comprendre comment les fonctionnalités aiment const enum



et sont générées namespace



. Mais parfois, la génération devient plus lente en raison de la nécessité de vérifier d' autres fichiers pour générer le résultat d'un fichier arbitraire.



Nous avons rarement besoin de fonctionnalités qui nécessitent des informations non locales. Les standards enum



peuvent être utilisés à la place const enum



, et les modules peuvent être utilisés à la place namespace



. Par conséquent, TypeScript a un indicateur isolatedModules



pour générer des erreurs sur les fonctionnalités qui nécessitent des informations non locales. Avec cet indicateur, vous pouvez utiliser en toute sécurité des outils qui utilisent des API TypeScript comme transpileModule



ou des compilateurs alternatifs comme Babel.



Ce code ne fonctionnera pas correctement lors de l'exécution avec la conversion de fichier en bac à sable car les valeurs doivent être insérées const enum



. Heureusement, il nous isolatedModules



préviendra à l'avance.

// ./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.

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

N'oubliez pas: isolatedModules



n'accélère pas automatiquement la génération de code. Il avertit uniquement de l'utilisation d'une fonctionnalité qui peut ne pas être prise en charge. Vous devez générer des modules de manière isolée dans différents outils de construction et API.



Vous pouvez créer des fichiers de manière isolée à l'aide des outils suivants:

• Le ts-loader a un indicateur transpileOnly , qui fournit des fichiers de création isolés en utilisant 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 peut définir l' option "transpileOnly" dans le champ "ts-node" du fichier tsconfig.json et possède également l'indicateur --transpile-only .

5. Enquête sur les problèmes

Il existe différentes façons de comprendre pourquoi quelque chose ne va pas.

5.1. Désactiver les plugins de l'éditeur

Les plugins peuvent affecter le fonctionnement de l'éditeur. Essayez de les désactiver (en particulier en ce qui concerne JavaScript / TypeScript) et voyez si les performances et la réactivité s'améliorent.



Certains éditeurs ont leurs propres recommandations de performances, lisez-les. Par exemple, Visual Studio Code a une page de conseils distincte .

5.2. diagnostics étendus

Vous pouvez exécuter TypeScript avec --extendedDiagnostics



pour voir où le temps du compilateur est passé:

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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Veuillez noter qu'il Total time



ne s'agira pas de la somme de tous les coûts de temps indiqués, car certains d'entre eux se chevauchent et certains ne sont pas du tout mesurés.



Les informations les plus pertinentes pour la plupart des utilisateurs:





Compte tenu de ces entrées, ce dont vous pourriez avoir besoin:

• Le nombre de fichiers / lignes de code correspond-il approximativement au nombre de fichiers du projet? Sinon, essayez d'utiliser --listFiles
  
  
  
  .
• Est-ce que les valeurs Program time
  
  
  
  ou ont l' I/O Read time
  
  
  
  air grand? Vérifiez si les paramètres sont corrects include
  
  
  
  /exclude
  
  
  
  

On dirait que quelque chose ne va pas avec d'autres horaires? Vous pouvez remplir un rapport de problème! Qu'est-ce qui vous aidera à diagnostiquer:

• Commencez par emitDeclarationOnly
  
  
  
  si la valeur est printTime
  
  
  
  élevée.
• Instructions de rapport sur les problèmes de performances du compilateur

5.3. showConfig

Il n'est pas toujours clair avec quels paramètres la compilation est effectuée au démarrage tsc



, d'autant plus que d' tsconfig.jsons



autres fichiers de configuration peuvent être étendus. showConfig



peut expliquer ce qu'il calculera tsc



.

tsc --showConfig

# or to select a specific config file...

tsc --showConfig -p tsconfig.json

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

5.4. traceRésolution

Lancer avec traceResolution



vous dira pourquoi le fichier a été ajouté à la compilation. Les données sont assez volumineuses, vous pouvez donc enregistrer le résultat dans un fichier:

tsc --traceResolution > resolution.txt

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Si vous trouvez un fichier qui ne devrait pas être là, vous pouvez corriger la liste include



/ exclude



dans le fichier tsconfig.json



, ou ajuster les paramètres comme types



, typeRoots



ou paths



.

5.5. Exécuter un tsc

Les utilisateurs rencontrent souvent des performances médiocres avec des outils de construction tiers tels que Gulp, Rollup, Webpack, etc. L'exécution tsc --extendedDiagnostics



pour trouver des écarts majeurs entre TypeScript et un outil tiers peut indiquer des erreurs dans les configurations externes ou une inefficacité.



Ce que vous devez vous demander:

• Y a-t-il une grande différence dans les temps de construction tsc
  
  
  
  avec l'outil intégré TypeScript?
• Si l'outil tiers dispose d'outils de diagnostic, la solution est-elle différente entre TypeScript et l'outil tiers?
• L'outil a-t-il sa propre configuration qui pourrait entraîner de mauvaises performances?
• L'outil a-t-il une configuration pour l'intégrer à TypeScript qui pourrait causer de mauvaises performances (comme les options pour ts-loader)?

5.6. Mettre à jour les dépendances

Parfois, des fichiers complexes peuvent affecter la vérification de type dans TypeScript .d.ts



. Rarement, mais cela arrive. Ceci est généralement résolu en mettant à niveau vers une version plus récente de TypeScript (plus efficacement) ou une version plus récente du package @types



(ce qui pourrait inverser la régression).

6. Problèmes fréquents

Face à des difficultés, vous voudrez en savoir plus sur les solutions aux problèmes courants. Si ce qui suit ne vous aide pas, vous pouvez signaler le problème .

6.1. Inclure et exclure mal configurés

Comme mentionné, les options include



/ exclude



peuvent être mal utilisées.

7. Compléter les rapports de problème

Si votre projet est déjà configuré correctement et de manière optimale, vous pouvez remplir un rapport de problème .



Un bon rapport contient une description facile à suivre du problème. Autrement dit, il contient une base de code de plusieurs fichiers qui peuvent être facilement clonés via Git. Dans ce cas, aucune intégration externe avec les outils d'assemblage n'est nécessaire, ils peuvent être appelés via tsc



ou utiliser du code isolé qui utilise l'API TypeScript. Vous ne pouvez pas hiérarchiser les bases de code qui nécessitent des appels et des paramètres complexes.



Oui, ce n'est pas toujours facile à réaliser. Surtout parce qu'il est difficile d'isoler la source du problème dans la base de code, et qu'il y a aussi des considérations de protection de la propriété intellectuelle. Dans certains cas, vous pouvez nous envoyer une NDA si vous pensez que le problème est d'une grande importance.



Quelle que soit la reproductibilité du problème, lors de la rédaction du rapport, suivez ces conseils, ils nous aideront à trouver une solution.

7.1. Rapport sur les problèmes de performances du compilateur

Parfois, des problèmes de performances se produisent pendant la génération et la modification. Ensuite, il est logique de se concentrer sur le compilateur TypeScript.



Tout d'abord, utilisez la version "nocturne" de TypeScript pour vous assurer que vous ne rencontrez pas de problème résolu:

npm install --save-dev typescript@next

# or

yarn add typescript@next --dev

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

La description du problème de performance doit inclure:

• Version installée de TypeScript ( npx tsc -v
  
  
  
  ou yarn tsc -v
  
  
  
  ).
• La version de Node sur laquelle TypeScript ( node -v
  
  
  
  ) s'exécutait .
• Résultat de l'exécution avec option extendedDiagnostics
  
  
  
  ( tsc --extendedDiagnostics -p tsconfig.json
  
  
  
  ).
• Idéalement, le projet lui-même est nécessaire pour démontrer le problème à résoudre.
• Journal du profileur du compilateur (fichiers isolate-*-*-*.log
  
  
  
  et *.cpuprofile
  
  
  
  ).

Profilage du compilateur



Il est important de nous fournir une trace de diagnostic en exécutant Node.js v10 + avec l'indicateur --trace-ic



et TypeScript avec l'indicateur --generateCpuProfile



:

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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Cela ./node_modules/typescript/lib/tsc.js



peut être remplacé par le chemin dans lequel votre version du compilateur TypeScript est installée. Et à la place, il tsconfig.json



peut s'agir de n'importe quel fichier de configuration TypeScript. Au lieu de cela profile.cpuprofile



- le fichier de sortie de votre choix.



Deux fichiers seront générés:

• --trace-ic
  
  
  
  enregistrera les données dans un fichier de vue isolate-*-*-*.log
  
  
  
  (par exemple isolate-00000176DB2DF130-17676-v8.log
  
  
  
  ).
• --generateCpuProfile
  
  
  
  enregistrera les données dans un fichier avec un nom de votre choix. Dans l'exemple ci-dessus, c'est profile.cpuprofile
  
  
  
  .

Remarque : ces fichiers peuvent contenir des informations provenant de votre espace de travail, notamment des chemins d'accès et du code source. Les deux fichiers sont créés en texte brut et vous pouvez les modifier avant de les joindre au rapport Github (par exemple, en supprimant les chemins susceptibles de révéler des informations sensibles).



Mais si vous avez des doutes quant à leur mise sur Github, écrivez-nous et vous pourrez envoyer les informations en privé.

7.2. Problèmes de performances de l'éditeur de rapports

Il peut y avoir de nombreuses raisons aux performances d'édition médiocres. Et l'équipe TypeScript ne peut affecter que les performances du service de langage JavaScript / TypeScript, ainsi que l'intégration entre le service de langage et certains éditeurs (par exemple, Visual Studio, Visual Studio Code, Visual Studio pour Mac et Sublime Text). Assurez-vous que tous les plugins tiers sont désactivés dans votre éditeur. Cela vérifiera que le problème est lié à TypeScript lui-même.



Les problèmes de performances de l'éditeur sont un peu plus complexes, mais les mêmes idées s'appliquent: les bases de code minimales clonées avec un problème reproductible sont idéales. Et dans certains cas, nous pouvons signer un NDA pour enquêter et isoler les problèmes.



Ajout de données depuistsc --extendedDiagnostics



, mais encore mieux s'il existe une trace TSServer.



Obtenir les journaux TSServer dans Visual Studio Code

1. Ouvrez la barre de commandes, puis:
2. Définissez l'option «typescript.tsserver.log»: «verbose»,
   
   
   
   .
3. Redémarrez VS Code et reproduisez le problème.
4. Dans VS Code, exécutez la commande TypeScript: Open TS Server log
   
   
   
   .
5. Le fichier doit s'ouvrir tsserver.log
   
   
   
   .

Remarque : Le journal TSServer peut contenir des informations provenant de votre espace de travail, notamment des chemins et du code source. Si vous avez des doutes quant à la mise sur Github, écrivez-nous et vous pourrez envoyer les informations en privé.