Hay formas sencillas de configurar TypeScript para acelerar la compilación y la edición. Y cuanto antes se implementen, mejor. También existen algunos enfoques populares para investigar las causas de la compilación y edición lentas, algunas correcciones y formas comunes de ayudar al equipo de TypeScript a investigar problemas.

1. Escribir código fácil de compilar

1.1. Preferencia por interfaces sobre intersecciones (intersección)

La mayoría de las veces, un alias simple para un tipo de objeto actúa de la misma manera que una interfaz.

interface Foo { prop: string }

type Bar = { prop: string };

Pero si necesita una combinación de dos o más tipos, puede extenderlos usando una interfaz o crear una intersección de tipos dentro de un alias. La diferencia entre estos enfoques es importante.

Las interfaces crean un único tipo de objeto aplanar que expone los conflictos de propiedad que generalmente son importantes de resolver. Y las intersecciones simplemente combinan propiedades de forma recursiva y, en algunos casos, generan never

. Además, las interfaces se representan mejor, mientras que los alias de tipo para las intersecciones no se pueden mostrar en la otra parte de la intersección. Las relaciones de tipos entre interfaces se almacenan en caché, a diferencia de los tipos de intersección. La última diferencia importante es que cuando se valida contra el tipo de intersección de destino, cada componente se valida antes de validarse / aplanarse.

Por lo tanto, se recomienda extender los tipos con interface

/ en extends

lugar de crear intersecciones de tipos.

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

1.2. Usar anotaciones de tipo

Agregar anotaciones de tipo, especialmente para los valores de retorno, puede ahorrarle mucho trabajo al compilador. Esto se debe en parte a que los tipos con nombre suelen ser más compactos que los tipos anónimos (que el compilador puede emitir), lo que reduce el tiempo que lleva leer y escribir archivos de declaración (por ejemplo, para compilaciones incrementales). El casting es muy conveniente, por lo que no es necesario hacerlo universalmente. Pero puede ser útil intentarlo cuando encuentre fragmentos lentos en su código.

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

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

1.3. Preferencia por tipos base sobre varios tipos

Los tipos múltiples son una gran herramienta: le permiten expresar el rango de valores posibles para un tipo.

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

Pero todo tiene un precio. Cada vez que se le pasa un argumento printSchedule

, debe compararse con cada elemento del conjunto. Este no es un problema para dos elementos. Pero si hay una docena de elementos en el conjunto, puede ralentizar la velocidad de compilación. Por ejemplo, para eliminar elementos redundantes, todos deben compararse en pares, esta es una función cuadrática. Estos controles pueden ocurrir cuando se cruzan conjuntos grandes, cuando la intersección de cada elemento del conjunto puede dar lugar a la aparición de tipos enormes que deben reducirse. Y todo esto se puede evitar utilizando subtipos en lugar de conjuntos.

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 ejemplo más realista es cuando se intenta modelar todos los tipos de elementos DOM integrados. En este caso, es preferible crear un tipo base HtmlElement

con elementos frecuentes, que se expanda con DivElement

, ImgElement

etc., en lugar de crear un conjunto pesado DivElement | /*...*/ | ImgElement | /*...*/

.

2. Uso de vínculos a proyectos

Al crear cualquier base de código grande de TypeScript, es útil organizarla en varios proyectos independientes . Cada uno de ellos tiene el suyo propio tsconfig.json

con dependencias en otros proyectos. Esto puede ayudar a evitar la descarga de demasiados archivos en una compilación y también puede facilitar la combinación y combinación de diferentes esquemas de base de código.

Hay algunas formas muy sencillas de dividir su código base en proyectos . Por ejemplo, un proyecto para un cliente, un proyecto para un servidor y un proyecto común entre ellos.

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

Las pruebas también se pueden separar en un proyecto separado.

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

La gente suele preguntar: "¿Qué tan grande debería ser el proyecto?" Es como preguntar: "¿Qué tan grande debe ser una función?" o "¿Qué tan grande debe ser la clase?" Depende mucho de la experiencia. Digamos que puede compartir código JS / TS usando carpetas, y si algunos componentes están lo suficientemente interconectados como para colocarse en una carpeta, entonces puede considerarlos que pertenecen al mismo proyecto. Además, evite proyectos grandes o pequeños. Si uno de ellos es más grande que todos los demás combinados, entonces esta es una mala señal. También es mejor no crear docenas de proyectos de un solo archivo porque esto aumenta la sobrecarga.

Puede leer acerca de los enlaces entre proyectos aquí .

3. Configuración de tsconfig.json o jsconfig.json

Los usuarios de TypeScript y JavaScript siempre pueden personalizar sus compilaciones utilizando el archivo tsconfig.json. Los archivos Jsconfig.json también se pueden usar para personalizar la edición de JavaScript .

3.1. Definición de archivos

Siempre asegúrese de que sus archivos de configuración no incluyan demasiados archivos a la vez.

Puede tsconfig.json

definir archivos de proyecto de dos formas:

lista files

;
listas include

y exclude

;

La principal diferencia entre los dos es que files

obtiene una lista de rutas de archivo de origen y include

/ exclude

usa patrones globales para identificar los archivos correspondientes.

Al definir files

, permitimos que TypeScript cargue archivos directamente de forma rápida. Esto puede resultar engorroso si el proyecto tiene muchos archivos y solo unos pocos puntos de entrada de alto nivel. También es fácil olvidarse de agregar nuevos archivos tsconfig.json

y luego se encuentra con un comportamiento extraño del editor.

include

/ exclude

no requiere que se identifiquen todos estos archivos, pero el sistema debería detectarlos revisando los directorios agregados. Y si hay muchos , la compilación puede ralentizarse. Además, en ocasiones la compilación incluye numerosos.d.ts

y archivos de prueba, que también pueden reducir la velocidad y aumentar el consumo de memoria. Finalmente, si bien exclude

existen valores predeterminados adecuados en algunas configuraciones, como los repositorios mono, existen carpetas "pesadas" como las node_modules

que se agregarán en el momento de la compilación.

Es mejor hacer esto:

Defina solo las carpetas de entrada de su proyecto (por ejemplo, el código fuente desde el que desea agregar durante la compilación y el análisis).
No mezcle archivos de origen de diferentes proyectos en la misma carpeta.
Si almacena pruebas en la misma carpeta de origen, asígneles un nombre para que puedan excluirse fácilmente.
Evite crear grandes artefactos de ensamblaje y carpetas de dependencia como node_modules

.

Nota: Sin una lista, la exclude

carpeta node_modules

se excluirá de forma predeterminada. Y si se agregará la lista, es importante indicarlo explícitamente node_modules

.

He aquí un ejemplo tsconfig.json

:

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

3.2. Control sobre la adición de @types

De forma predeterminada, TypeScript agrega automáticamente todos los node_modules

paquetes que se encuentran en una carpeta @types

, ya sea que los haya importado o no. Esto es para hacer que ciertas funciones “simplemente funcionen” cuando se usa Node.js, Jasmine, Mocha, Chai, etc., ya que estas herramientas / paquetes no se importan, sino que se cargan en el entorno global.

A veces, esta lógica puede ralentizar la compilación y edición del programa. E incluso provocar conflictos de declaración en numerosos paquetes globales que provocan errores como este:

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

Si no se necesitan paquetes globales, puede definir una carpeta vacía en la opción "tipos" en 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 necesita paquetes globales, agréguelos al campo types

.

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

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

3.3. Generación incremental de proyectos

La bandera --incremental

permite que TypeScript guarde el último estado compilado en un archivo .tsbuildinfo

. Se utiliza para definir el conjunto mínimo de archivos que se pueden volver a comprobar / sobrescribir desde la última ejecución, como el modo --watch

en TypeScript.

La generación incremental está habilitada de forma predeterminada cuando se usa la composite

marca de enlace entre proyectos, pero también puede acelerar cualquier otro proyecto.

3.4. Omitir validación .d.ts

De forma predeterminada, TypeScript volverá a comprobar todos los .d.ts

archivos de un proyecto para encontrar problemas e incoherencias. Pero esto generalmente no es necesario. La mayoría de las veces, ya se sabe que estos archivos funcionan: los métodos de expansión de tipos ya se han verificado, pero las declaraciones importantes aún se verificarán.

TypeScript permite que una bandera skipDefaultLibCheck

omita la verificación de tipos en los .d.ts

archivos suministrados (por ejemplo, in lib.d.ts

).

También puede habilitar la bandera skipLibCheck

para omitir la verificación de todos los .d.ts

archivos en la compilación.

Estas dos opciones a menudo ocultan errores de configuración y conflictos de .d.ts

archivos, por lo que se recomienda usarlas solo para acelerar la compilación.

3.5. Verificaciones variadic más rápidas

¿Lista de perros o animales? ¿Puedes conducir List<Dg>

a List<Animls>

? Una forma fácil de encontrar la respuesta es comparar estructuralmente los tipos, elemento por elemento. Desafortunadamente, esta solución puede resultar muy cara. Pero si sabemos lo suficiente sobre List<>

, entonces podemos reducir los controles de asignación de determinar si es permisible para referirse Dog

a Animal

(es decir, sin comprobar cada elemento List<>

). En particular, necesitamos conocer la variabilidad del tipo de parámetro T

. El compilador solo puede aprovechar al máximo la optimización si el indicador está activado strictFunctionTypes

(de lo contrario, utilizará una verificación estructural más lenta pero más indulgente). Por lo tanto, se recomienda construir con la bandera --strictFunctionTypes

(que está habilitada por defecto en --strict

).

4. Configuración de otras herramientas de montaje

TypeScript a menudo se compila con otras herramientas de construcción, especialmente cuando se crea una aplicación web que puede usar bundler. Solo podemos ofrecer algunas ideas, pero en general este enfoque puede generalizarse.

Además de esta parte, asegúrese de leer sobre el rendimiento de su herramienta elegida, por ejemplo:

La parte ts-loader en el artículo Faster Builds .
La parte impresionante del cargador de mecanografiado en el artículo Problemas de rendimiento .

4.1. Verificación de tipo simultánea

La verificación de tipos generalmente requiere información de otros archivos y es relativamente costosa en comparación con otros pasos como convertir / escribir código. Dado que la verificación de tipos puede llevar bastante tiempo, puede afectar el ciclo de desarrollo interno. Es decir, el ciclo de edición, compilación y ejecución será más largo, lo que es desagradable.

Por lo tanto, muchas herramientas de compilación pueden verificar los tipos en un proceso separado, sin bloquear la creación de archivos. Aunque en este caso, se puede ejecutar código erróneo antes de que TypeScript informe el error en su herramienta de compilación. La mayoría de las veces, primero verá errores en el editor y no esperará a que se ejecute el código.

Un ejemplo es fork-ts-checker-webpack-plugin para Webpack, o similarimpresionante-mecanografiado-loader .

4.2. Creación de archivos aislados

De forma predeterminada, la creación de archivos en TypeScript requiere información semántica que puede no ser local para el archivo. Esto es necesario para comprender cómo se generan las características const enum

y cómo se generan namespace

. Pero a veces la generación se vuelve más lenta debido a la necesidad de verificar otros archivos para generar el resultado de un archivo arbitrario.

Rara vez necesitamos funciones que requieran información no local. En enum

su lugar const enum

, se pueden usar regulares y en su lugar se pueden usar módulos namespace

. Por lo tanto, TypeScript tiene una bandera isolatedModules

para lanzar errores en funciones que requieren información no local. Con esta marca, puede utilizar de forma segura herramientas que utilizan API de TypeScript como transpileModule

compiladores alternativos como Babel.

Este código no funcionará correctamente en tiempo de ejecución con la conversión de archivos aislados porque los valores deben estar en línea const enum

. Afortunadamente, nos isolatedModules

avisará con antelación.

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

Recuerde: isolatedModules

no acelera automáticamente la generación de código. Solo advierte sobre el uso de una función que puede no ser compatible. Necesita generar módulos de forma aislada en diferentes herramientas de compilación y API.

Puede crear archivos de forma aislada utilizando las siguientes herramientas:

El ts-loader tiene un indicador transpileOnly , que proporciona archivos de creación aislados utilizando 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 puede definir la opción "transpileOnly" en el campo "ts-node" del archivo tsconfig.json y también tiene la marca --transpile-only .

5. Investigación de problemas

Hay diferentes formas de averiguar por qué algo va mal.

5.1. Deshabilitar los complementos del editor

Los complementos pueden afectar el funcionamiento del editor. Intente deshabilitarlos (especialmente los relacionados con JavaScript / TypeScript) y vea si el rendimiento y la capacidad de respuesta mejoran.

Algunos editores tienen sus propias recomendaciones para mejorar el rendimiento, léalas. Por ejemplo, Visual Studio Code tiene una página de sugerencias separada .

5.2. ExtendedDiagnostics

Puede ejecutar TypeScript con --extendedDiagnostics

para ver dónde se gasta el tiempo del compilador:

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

Tenga en cuenta que Total time

no será la suma de todos los costos de tiempo enumerados, ya que algunos de ellos se superponen y otros no se miden en absoluto.

La información más relevante para la mayoría de usuarios:

Campo	Valor
`Files`	La cantidad de archivos incluidos en el programa (qué tipo de archivos puede ver usando `--listFiles` ).
`I/O Read time`	Tiempo dedicado a la lectura del sistema de archivos. Esto incluye la lectura de carpetas de `include` .
`Parse time`	Tiempo dedicado a escanear y analizar el programa.
`Program time`	El tiempo total para leer del sistema de archivos, escanear y analizar el programa, así como otros cálculos de gráficos. Estas etapas se combinan aquí porque deben habilitarse y cargarse tan pronto como se agreguen mediante `import` y `export` .
`Bind time`	Tiempo dedicado a reunir información semántica diversa que es local para un archivo específico.
`Check time`	El tiempo dedicado a verificar los tipos en el programa.
`transformTime time`	Tiempo dedicado a reescribir AST de TypeScript (árboles que representan archivos de origen) en formularios que funcionan en entornos de ejecución heredados.
`commentTime`	Tiempo dedicado a evaluar comentarios en archivos generados.
`I/O Write time`	Tiempo dedicado a escribir y actualizar archivos en disco.
`printTime`	El tiempo necesario para calcular la representación de cadena del archivo generado y guardarlo en el disco.

Dadas estas entradas, lo que podría necesitar:

¿El número de archivos / líneas de código corresponde aproximadamente al número de archivos del proyecto? Si no es así, intente usar --listFiles

.
¿ Valores Program time

o I/O Read time

apariencia grande? Compruebe si la configuración es correcta include

/exclude

¿Parece que hay algún problema con otros tiempos? ¡Puede completar un informe de problemas! Qué te ayudará a diagnosticar:

Empiece por emitDeclarationOnly

si el valor es printTime

alto.
Instrucciones para informar problemas de rendimiento del compilador

5.3. showConfig

No siempre está claro con qué configuraciones se realiza la compilación al inicio tsc

, especialmente considerando que tsconfig.jsons

otros archivos de configuración se pueden extender. showConfig

puede explicar lo que calculará tsc

.

tsc --showConfig

# or to select a specific config file...

tsc --showConfig -p tsconfig.json

5.4. traceResolution

Ejecutar con traceResolution

le dirá por qué se agregó el archivo a la compilación. Los datos son bastante extensos, por lo que puede guardar el resultado en un archivo:

tsc --traceResolution > resolution.txt

Si encuentra un archivo que no debería estar allí, puede corregir la lista include

/ exclude

en el archivo tsconfig.json

o ajustar la configuración como types

, typeRoots

o paths

.

5.5. Ejecutando un tsc

Los usuarios a menudo experimentan un rendimiento deficiente con herramientas de compilación de terceros como Gulp, Rollup, Webpack, etc. Ejecutar tsc --extendedDiagnostics

para encontrar discrepancias importantes entre TypeScript y una herramienta de terceros puede indicar errores en la configuración externa o ineficiencia.

Lo que necesitas preguntarte:

¿Existe una gran diferencia en los tiempos de compilación tsc

con la herramienta integrada TypeScript?
Si la herramienta de terceros tiene herramientas de diagnóstico, ¿la solución es diferente entre TypeScript y la herramienta de terceros?
¿Tiene la herramienta su propia configuración que podría estar provocando un rendimiento deficiente?
¿La herramienta tiene una configuración para integrarla con TypeScript que podría estar causando un rendimiento deficiente (como opciones para ts-loader)?

5.6. Actualizar dependencias

A veces, los archivos computacionalmente complejos pueden afectar la verificación de tipos en TypeScript .d.ts

. Rara vez, pero sucede. Esto generalmente se resuelve actualizando a una versión más reciente de TypeScript (de manera más eficiente) o una versión más nueva del paquete @types

(que podría revertir la regresión).

6. Problemas frecuentes

Cuando se enfrente a dificultades, querrá aprender sobre soluciones a problemas comunes. Si lo siguiente no ayuda, puede informar el problema .

6.1. Incluir y excluir configurados incorrectamente

Como se mencionó, las opciones include

/ se exclude

pueden usar incorrectamente.

Problema	Porque	Corrección
`node_modules` se agregó accidentalmente desde una subcarpeta más profunda.	No estaba configurado `exclude`	`"exclude": ["/node_modules", "/.*/"]`
`node_modules` se agregó accidentalmente desde una subcarpeta más profunda.	`"exclude": ["node_modules"]`	`"exclude": ["/node_modules", "/.*/"]`
Los archivos ocultos con un punto se agregan aleatoriamente (por ejemplo `.git` ).	`"exclude": ["**/node_modules"]`	`"exclude": ["/node_modules", "/.*/"]`
Se agregaron archivos inesperados.	No estaba configurado `include`	`"include": ["src"]`

7. Completar informes de problemas

Si su proyecto ya está configurado de manera correcta y óptima, puede completar un informe de problemas .

Un buen informe contiene una descripción fácil de seguir del problema. Es decir, contiene una base de código de varios archivos que se pueden clonar fácilmente a través de Git. En este caso, no hay necesidad de integración externa con herramientas de ensamblaje, se puede llamar a través de ellas tsc

o puede usar código de espacio aislado que usa la API de TypeScript. No puede priorizar bases de código que requieran configuraciones y llamadas complejas.

Sí, esto no siempre es fácil de lograr. Especialmente porque es difícil aislar la fuente del problema dentro del código base, y también existen consideraciones de protección de la propiedad intelectual. En algunos casos, puede enviarnos un NDA si cree que el problema es de gran importancia.

Independientemente de la reproducibilidad del problema, al completar el informe, siga estos consejos, que nos ayudarán a encontrar una solución.

7.1. Informe de problemas de rendimiento del compilador

Ocasionalmente, se producen problemas de rendimiento durante la compilación y la edición. Entonces tiene sentido centrarse en el compilador de TypeScript.

Primero, use la versión "nocturna" de TypeScript para asegurarse de que no se encuentre con un problema resuelto:

npm install --save-dev typescript@next

# or

yarn add typescript@next --dev

La descripción del problema de rendimiento debe incluir:

Versión instalada de TypeScript ( npx tsc -v

o yarn tsc -v

).
La versión de Node en la que se estaba ejecutando TypeScript ( node -v

).
Resultado de ejecutar con la opción extendedDiagnostics

( tsc --extendedDiagnostics -p tsconfig.json

).
Idealmente, el proyecto en sí es necesario para demostrar el problema en cuestión.
Registro del generador de perfiles del compilador (archivos isolate-*-*-*.log

y *.cpuprofile

).

Perfilado del compilador

Es importante proporcionarnos un seguimiento de diagnóstico ejecutando Node.js v10 + con la bandera --trace-ic

y TypeScript con la bandera --generateCpuProfile

:

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

Esto ./node_modules/typescript/lib/tsc.js

se puede reemplazar por cualquier ruta en la que esté instalada su versión del compilador de TypeScript. Y en su lugar tsconfig.json

puede ser cualquier archivo de configuración de TypeScript. En su lugar profile.cpuprofile

, el archivo de salida de su elección.

Se generarán dos archivos:

--trace-ic

guardará los datos en un archivo de vista isolate-*-*-*.log

(por ejemplo isolate-00000176DB2DF130-17676-v8.log

).
--generateCpuProfile

guardará los datos en un archivo con el nombre de su elección. En el ejemplo anterior, esto es profile.cpuprofile

.

Nota : Estos archivos pueden contener información de su espacio de trabajo, incluidas rutas y código fuente. Ambos archivos se crean en texto sin formato y puede editarlos antes de adjuntarlos al informe de Github (por ejemplo, eliminando las rutas que podrían revelar información confidencial).

Pero si tienes alguna duda sobre ponerlas en Github, escríbenos y podrás enviarnos la información de forma privada.

7.2. Problemas de rendimiento del editor de informes

Puede haber muchas razones para un rendimiento de edición deficiente. Y el equipo de TypeScript solo puede afectar el rendimiento del servicio de lenguaje JavaScript / TypeScript, así como la integración entre el servicio de lenguaje y ciertos editores (como Visual Studio, Visual Studio Code, Visual Studio para Mac y Sublime Text). Asegúrese de que todos los complementos de terceros estén deshabilitados en su editor. Esto garantizará que el problema esté relacionado con el propio TypeScript.

Los problemas de rendimiento del editor son un poco más complejos, pero se aplican las mismas ideas: las bases de código mínimas clonadas con un problema reproducible son ideales. Y en algunos casos, podemos firmar un acuerdo de confidencialidad para investigar y aislar problemas.

Añadiendo datos detsc --extendedDiagnostics

, pero aún mejor si hay un rastro de TSServer.

Obtener registros de TSServer en Visual Studio Code

Abra la barra de comandos, luego:
Configure la opción «typescript.tsserver.log»: «verbose»,

.
Reinicie VS Code y reproduzca el problema.
En VS Code, ejecute el comando TypeScript: Open TS Server log

.
El archivo debería abrirse tsserver.log

.

Nota : El registro de TSServer puede contener información de su espacio de trabajo, incluidas rutas y código fuente. Si tienes alguna duda sobre ponerlo en Github, escríbenos y podrás enviarnos la información en privado.

Rendimiento de TypeScript