Compilaciones de TypeScript más rápidas con --isolatedDeclarations

Hola a todos. Bienvenidos a mi charla, Acelerando las construcciones de TypeScript. Mi nombre es Tiziano Cernico-Adragomir. Soy un ingeniero de software en Bloomberg en el equipo de infraestructura de TypeScript JavaScript, y también soy un colaborador del compilador de TypeScript.

Y hoy quiero hablar sobre el rendimiento de la construcción, especialmente el rendimiento de la construcción en monorepos. Y vamos a hablar sobre una próxima característica de TypeScript que hemos estado desarrollando en colaboración con Bloomberg, Google y Microsoft. Puedes echar un vistazo a esta característica en nuestro repositorio público de GitHub en nuestra bifurcación de TypeScript. Pero también vamos a hablar de ello hoy.

Entonces, ¿cuál es la motivación para esta característica? Bueno, si pasas cualquier cantidad de tiempo en Twitter, definitivamente encontrarás personas que se quejan sobre el rendimiento incorporado en TypeScript. Y estas quejas no son infundadas. Desafortunadamente, la comprobación de tipos puede ser lenta, especialmente si tienes mucho código en muchos proyectos en un monorepo. Entonces, la pregunta es, ¿qué podemos hacer al respecto? Bueno, podríamos optimizar el compilador, y el equipo de TypeScript definitivamente ha estado haciendo eso. Si revisas las notas de la versión para las últimas versiones, verás que cada versión trae nuevas optimizaciones al compilador. Y eso es un gran trabajo. También podríamos reescribir el compilador, y hay esfuerzos ahí fuera que están tratando de hacer esto. Estamos emocionados de ver a dónde van también. Pero intentamos un enfoque diferente. Pensamos en ejecutar las cosas en paralelo, porque mucho del hardware de hoy es multicore, la gente tiene muchos núcleos en sus escritorios y sus portátiles. Y sería genial si pudiéramos aprovechar esos para hacer las cosas más rápidas para las personas cuando construyen sus proyectos. Así que vamos a ejecutar el compilador en paralelo. Veamos qué ganancias de rendimiento podríamos obtener. Lo que hicimos en Silent Bloomer, tomamos uno de nuestros propios monorepos. Era un monorepo de 23 proyectos. Tiene más de 100,000 líneas de TypeScript código y un gráfico de dependencia muy profundo, así que puedes pensar en algo así, muchos proyectos con muchas dependencias. Y tratamos de ver qué ganancias podríamos obtener al ejecutar el comprobador de tipos en paralelo para este monorepo. Tomamos una línea de base inicial usando el soporte de proyecto compuesto incorporado de TypeScript, y obtuvimos tiempos de construcción de alrededor de 60 segundos a 30, dependiendo del hardware. Ahora, TypeScript-B, que es el soporte de proyecto compuesto en TypeScript, es de un solo hilo. No intentará construir nada en paralelo, por lo que todos estos proyectos se comprueban de tipo individualmente en orden de sus dependencias. Así que veamos qué podríamos hacer si intentamos ejecutar el compilador en paralelo. Lo que hicimos fue ejecutar una instancia separada del compilador para cada proyecto.

Ahora, no hicimos esto de una manera ingenua. Hubo algunas optimizaciones que sí hicimos. Por ejemplo, agrupamos todos los proyectos en varios trabajadores, y cada uno de estos trabajadores tenía una caché de archivos compartida y una caché compartida del árbol de sintaxis del archivo fuente, que ya son optimizaciones que TypeScript hace para su soporte de proyectos compuestos de todos modos. Así que solo estábamos tratando de emular eso.

Ahora, el problema con el que nos encontramos de inmediato es que los proyectos no son independientes. Así que no podemos simplemente ejecutar todo en paralelo. Necesitamos esperar a que las dependencias terminen de construirse. Entonces, por ejemplo, para el diagrama que mostré antes de las dependencias, obtendríamos una ejecución que se ve algo así. Y ya podemos ver que tenemos un gran límite en el paralelismo y solo hay dos proyectos que se ejecutan en paralelo al mismo tiempo. Así que solo dos proyectos se verifican en paralelo. E incluso en nuestro monorepo de muestra con 23 proyectos, solo conseguiríamos construir unos cuatro en paralelo.

Ahora, ¿qué significa esto realmente? Por ejemplo, en un portátil con 12 núcleos, que es lo que vemos aquí en esta imagen, solo utilizamos parte de esa potencia de cálculo. Podemos ver que incluso mientras se ejecuta la construcción, hay mucha potencia de CPU que aún se deja sin utilizar. Muchos núcleos de CPU que simplemente están allí inactivos. Así que definitivamente no es un buen comienzo para ejecutar cosas en paralelo.

Veamos a veces qué tipo de mejoras podríamos obtener si hiciéramos esto? Y la respuesta es que definitivamente obtendremos mejoras, pero simplemente no son tan grandes. Quiero decir, hay una mejora de aproximadamente el 10-20% que obtenemos al ejecutar cosas en paralelo utilizando este enfoque, que es nuevamente mejor que lo que teníamos, pero no es algo que vaya a ser dramático.

Entonces, ¿cómo podemos aumentar el paralelismo disponible? ¿Cómo podemos ejecutar más cosas en paralelo? Bueno, para eso, primero necesitamos entender exactamente qué es lo que TypeScript realmente hace, y lo que hace son tres cosas. Realiza la comprobación de tipos, emite declaraciones, y emite JavaScript. Ahora, estas cosas no son perfectamente independientes, a saber, la emisión de declaraciones depende del resultado de la comprobación de tipos. Pero para cada uno de nuestros proyectos, TypeScript hará estas tres cosas. Así que, dentro de la construcción de cada uno de nuestros proyectos, estas tres cosas tienen que suceder.

Ahora, hay una idea clave aquí, a saber, que lo que se necesita para desbloquear un proyecto para iniciar su fase de comprobación de tipos es que necesita tener disponibles todas las declaraciones de sus dependencias. Así que, la emisión de declaraciones es lo que realmente se necesita para las dependencias. Realmente no nos importa si la dependencia ha terminado la comprobación de tipos si podemos obtener sus declaraciones. Así que, la cola de dependencias real se vería más como esto, ¿verdad? Cada fase de comprobación de tipos depende de la emisión de declaraciones de sus dependencias, no necesariamente de la comprobación de tipos. Eso es una idea interesante, pero mientras todavía tengamos esta dependencia entre la comprobación de tipos y la emisión de declaraciones, el hecho de que este sea el caso, el hecho de que dependamos de la emisión de declaraciones realmente no nos ayuda porque necesitamos hacer la comprobación de tipos de todos modos. Entonces, ¿podríamos eliminar esta dependencia? Bueno, para eso, deberíamos primero mirar por qué la emisión de JavaScript es tan independiente de la comprobación de tipos. ¿Cómo es eso? De hecho, incluso tenemos herramientas que emiten JavaScript sin la necesidad de un comprobador de tipos. Lo hacen completamente independientemente de TypeScript. ¿Cómo se permite esto? Bueno, hace unos años, TypeScript añadió un nuevo modo a TypeScript llamado módulos aislados. Entonces, ¿qué hace exactamente los módulos aislados? Bueno, asegura que cada archivo puede ser transpilado de TypeScript a JavaScript individualmente. Básicamente elimina cualquier dependencia en la comprobación de tipos de la emisión de JavaScript. Así que esto significa que la emisión de JavaScript se convierte en un proceso puramente sintáctico. Las herramientas todavía necesitan entender la sintaxis de TypeScript. Así que, cada vez que obtenemos una nueva sintaxis en TypeScript, todas las herramientas que emiten JavaScript necesitan entender esta nueva sintaxis. Pero la ventaja es que en realidad no necesitan entender todas las reglas semánticas de TypeScript. Solo necesitan entender la sintaxis lo suficiente como para poder eliminarla. Así que, básicamente, cuando hacemos la emisión de JavaScript, empezamos con un archivo de TypeScript, y lo que sucede dentro de un emisor de JavaScript es que todas las anotaciones de tipo son eliminadas, ¿verdad? Y este es un proceso muy simple. No es difícil construir tal transformación. Al menos no es difícil comparado con la construcción de un comprobador de tipos completo.

Entonces, ¿podríamos usar un enfoque similar para eliminar esta dependencia entre la emisión de declaraciones y la verificación de tipos? Para eso, tenemos que analizar un poco en qué consiste exactamente la emisión de declaraciones. En su mayor parte, también es un proceso de sustracción donde simplemente eliminamos cosas del archivo de TypeScript, excepto que ya no eliminamos los tipos. Estamos eliminando la implementación, por ejemplo, el cuerpo de la función, el cuerpo del constructor. Todo esto desaparece en los archivos de declaración.

Sin embargo, hay una excepción, en este caso, el tipo de retorno de esta función, porque si el desarrollador no especifica el tipo de retorno, la emisión de declaraciones debe acceder al verificador de tipos y averiguar cuál será el tipo de retorno de esta función. Y por eso se requiere la verificación de tipos para la emisión de declaraciones. Si todos escribieran todos los tipos en el archivo de TypeScript, en realidad no necesitaríamos el verificador de tipos para la emisión de declaraciones. Esta es una forma en la que podríamos eliminar la dependencia si especificamos todos los tipos, lo que nos permitiría desbloquear las dependencias más rápido.

Ya existen reglas de linting que podrían hacer cumplir esto, pero sería útil tener algo incorporado en la compilación real que garantice a otras herramientas qué anotaciones son necesarias. Por eso decidimos agregar una nueva bandera a TypeScript que llamamos declaraciones aisladas. Declaraciones aisladas es la nueva característica que estamos implementando. Veamos qué significa esta característica. Nuestra primera idea fue agregar anotaciones de tipo a todos los valores que se incluyen en los archivos de declaración. Esto se refiere principalmente a los valores exportados, aunque también hay algunas formas indirectas en las que los valores pueden incluirse en los archivos de declaración, incluso si no se exportan explícitamente.

Hicimos algunas excepciones. En algunos casos, los valores se pueden inferir fácilmente y tal vez podamos permitirlos sin tener anotaciones de tipo explícitas. Pero lo que es seguro es que el verificador de tipos en sí no puede participar en la emisión de declaraciones, porque queremos que la emisión de declaraciones sea puramente una transformación sintáctica donde simplemente eliminamos la implementación y no tenemos que acceder al verificador de tipos para obtener información de tipo del código fuente.

Entonces, la siguiente pregunta lógica es, ¿tengo que anotar todos los tipos? Quiero señalar que no tienes que hacer nada a menos que optes por hacerlo. Si estás satisfecho con tus compilaciones de TypeScript, si estás satisfecho con la forma en que TypeScript fue y con tus tiempos de compilación, puedes mantener tu proyecto tal como está. Nadie te obliga a adoptar esto. Si tus dependencias adoptan esto, realmente no te importará porque solo estás consumiendo su archivo de declaración, por lo que no será algo en lo que todos tengan que optar.

Entonces, nuestra idea inicial, sin embargo, era que sí, necesitaríamos especificar anotaciones de tipo en todo. Resulta que esto hace que la conversión de proyectos grandes sea dolorosa y no es la mejor experiencia para los desarrolladores, especialmente al ver algunas de estas expresiones, podrías deducir fácilmente que sí, de hecho, el tipo de algo es un número. Pasamos por tres fases. Básicamente, la primera fue donde pensamos que no haríamos ninguna inferencia en este modo. La segunda fue donde pensamos que tal vez alguna inferencia trivial está bien. Y la última, que finalmente rechazamos, fue donde hacemos mucha más inferencia. Pero también nos encontramos con algunos problemas que veremos en unos momentos. Veamos cómo se vería nuestro código con cada una de estas versiones.

Entonces, sin inferencia. Lo que esto significaría es que tendrías que especificar tipos en absolutamente todo. Por ejemplo, estás asignando 20 a la variable margen. Es bastante obvio que el tipo debería ser número aquí, pero no permitimos ninguna anotación, por lo que tendrías que especificarlo. Tendrías que especificarlo para esta constante, básicamente duplicando el literal en ambos lugares, tanto en la posición del tipo como en el inicializador. Se vuelve aún peor para cosas como objetos literales, donde tienes que duplicar los nombres de las propiedades y los valores, y realmente se vuelve muy doloroso hacerlo. Para constantes que se inicializan con una función, bueno, tendrías que copiar la lista de parámetros nuevamente en la anotación de tipo, y también especificar el tipo de retorno. Y nuevamente, para campos, incluso si los estás inicializando con valores muy básicos, que debería ser obvio de qué tipo son, aún tendríamos que especificar el tipo explícitamente. Nuevamente, esto habría sido bastante doloroso y habría dificultado mucho que alguien realmente adopte esta característica. Así que decidimos hacer que nuestra declaración sea un poco más inteligente. Entonces, si vemos un literal de número, bueno, el tipo allí es obviamente número. Por lo que no necesitas especificarlo. Lo mismo para los tipos literales. Para los tipos de objeto, es un poco más complicado, pero no es imposible deducir el tipo a partir del inicializador. Así que decidimos que también podemos admitir esto. Para funciones que, para constantes que se inicializan con una función, bueno, no necesitas especificar toda la firma de la función como una anotación de tipo. Podemos extraer la mayor parte de la información que necesitamos de la lista de parámetros.

Sin embargo, deberás especificar el tipo de retorno porque no queremos tener que entrar en el cuerpo de la función misma y buscar cualquier retorno e intentar sintetizar un tipo de retorno basado en eso. Y para los campos de función, y para los campos de clase, nuevamente, puedes simplemente omitirlos si el inicializador es lo suficientemente claro para que podamos inferir un tipo.

¿Qué pasa si queremos más, verdad? Estábamos muy emocionados por nuestro éxito inicial con esta forma trivial de inferencia, y decidimos, bueno, tal vez podamos hacer más. Tal vez podamos inferir más cosas. Y el problema es que el emisor de declaraciones de TypeScript es muy inteligente, y queremos que nuestros emisores sean simples y, con suerte, rápidos. Así que no queremos que el emisor de declaraciones, por ejemplo, tenga que buscar información en otros archivos. Así que pongamos un ejemplo. Digamos que tenemos una variable, y la estamos inicializando con el valor de otra variable. ¿Podríamos inferir trivialmente un tipo para orientation? ¿Qué tipo podríamos escribir en los archivos de declaración sin tener que involucrar al comprobador de tipos? Podríamos intentar usar typeOfHorizontal. Esto parece encajar muy bien. typeOf nos dará el tipo de la variable, y orientation debería tener el mismo tipo que lo que estamos asignando, ¿verdad? Bueno, a veces funciona. Por ejemplo, si horizontal está definido como una variable de tipo string, entonces sí, el tipo de horizontal será el mismo que el tipo de orientation porque ambos serán strings, y todo funcionaría muy bien. Sin embargo, si horizontal es una constante, entonces lo que realmente obtenemos para horizontal es el tipo literal horizontal. Entonces, ¿qué sucede cuando asignas esa variable a una variable mutable es que TypeScript realmente ampliará el tipo, por lo que orientation tendrá tipo string. Así que en este caso, el tipo de la variable horizontal será diferente que el tipo de la variable orientation porque tendremos básicamente string en un lado y horizontal en el otro lado. Así que no funciona en todos los casos. Entonces, ¿la respuesta es, podemos hacer más inferencia? La respuesta es sí, pero probablemente no siempre estaremos en lo correcto, por lo que las declaraciones tendrían que ser omitidas de manera optimista. Esto básicamente causa algunos problemas, sin embargo, porque lo que estamos diciendo aquí es que, bueno, un emisor de declaraciones podría producir declaraciones sin el comprobador de tipos, pero podrían estar equivocadas. Y luego TypeScript en sí podría regresar y generar un error al mirar toda la información en el sistema de tipos y decir, bueno, en este caso particular, si estás usando declaraciones aisladas y estás usando un emisor de declaraciones independiente, no podría haber sabido cuál era el tipo correcto allí. Así que esto es posible, pero crea un modelo mental muy complicado, lo que dificulta mucho la comprensión. Además, los errores serían mucho más difíciles de entender porque tendríamos que decirles a las personas por qué exactamente están teniendo un error en una cierta construcción. Y lo que obtuvimos fueron errores que sonaban algo como, este tipo que se infiere en las declaraciones aisladas es diferente de este otro tipo que se infiere normalmente por TypeScript. Y suena como si el compilador estuviera discutiendo consigo mismo. Las declaraciones aisladas son una cosa, el TSC normal dice otra cosa.

Y los desarrolladores involucrados básicamente no tienen participación en este proceso. Por lo tanto, todo esto podría resultar en degradar la experiencia del desarrollador en lugar de mejorarla, que fue la razón por la que queríamos más inferencia en primer lugar. Definitivamente, agregar más inferencias que no siempre son correctas no es la mejor opción.

Sin embargo, aún queríamos asegurarnos de que las personas tuvieran un tiempo más fácil adoptando esta característica. ¿Cómo podríamos asegurarlo? Bueno, decidimos agregar una solución rápida. La información ya está presente allí. Solo necesitamos insertar un tipo en nuestro código. Visual Studio Code ya tiene toda la información, el servicio de lenguaje que se ejecuta allí ya sabe cuáles son los tipos de todas las variables incluso si no están explícitos. Entonces, lo que podríamos hacer si hay una declaración aislada es simplemente usar una solución rápida para insertar el tipo sin tener que escribirlo nosotros mismos lo cual creo que definitivamente ayudará a todos los desarrolladores a adoptar esta característica.

Quiero enviar un agradecimiento especial a Hannah Jewell de Google que trabajó extensamente en esta característica y la mayor parte es gracias a ella.

Entonces, ¿cómo mejorarían las declaraciones aisladas a TypeScript? Bueno, esperamos mejorarla de varias formas. Con esta característica, en primer lugar, esperamos mejorar la velocidad, al pasar el verificador de tipos para sintetizar nuevos tipos probablemente mejorará la velocidad del límite de declaraciones por sí mismo. Esperamos desbloquear mucho más paralelismo. Si podemos emitir las declaraciones de antemano, los proyectos no necesitan esperar a que la fase de verificación de tipos de todas sus dependencias termine. Ya tienen las declaraciones y pueden realizar su propia verificación de tipos con eso. También esperamos mejorar la compatibilidad con otras herramientas. Como dije, ya existen herramientas que generan JavaScript a partir de TypeScript. Esperamos crear un ecosistema similar de herramientas que puedan emitir archivos de declaración sin el uso del verificador de tipos, pero que sean 100% compatibles con las declaraciones actuales de TypeScript. Y también esperamos mejorar la transparencia. A veces, los desarrolladores olvidan escribir tipos para sus valores exportados. Y a veces el verificador de tipos sintetiza algunas cosas que no son particularmente amigables para el desarrollador. Son tipos muy grandes o tipos sin ningún significado semántico, lo que resulta en una mala experiencia del desarrollador para los clientes de esas bibliotecas. Entonces, si las personas se ven obligadas a escribir estos tipos en el código, probablemente pensarán más en ellos y las declaraciones probablemente tendrán una mejor calidad solo por esto.

Pero volviendo a nuestro experimento de ejecutar la compilación de un monorepo en paralelo, vimos que sin declaraciones aisladas, había una cantidad limitada de paralelismo. Con las declaraciones aisladas, esperamos aumentar la cantidad de paralelismo disponible. Vimos que en la otra versión, esto era bastante limitado. En el mejor de los casos, dos proyectos podían verificar los tipos en paralelo en este ejemplo. Lo que queremos hacer es cargar todas las declaraciones de antemano, para desbloquear todos los proyectos lo más rápido posible. Queremos pasar de este diagrama a este diagrama. Con suerte, la diferencia entre estos dos es que esta vez no necesitaremos esperar a TypeScript porque la verificación de tipos se realizará mucho más rápido si podemos hacer todo esto en paralelo. Esa era la esperanza. Sin números reales, teóricamente esto podría funcionar. Pero en realidad no sabíamos qué tipo de mejoras de rendimiento estábamos viendo en proyectos reales.

Entonces, lo que hicimos fue convertir nuestro monorepo de muestra para usar declaraciones aisladas. Y tratamos de ver qué tipo de mejora de rendimiento obtendríamos al intentar compilar en paralelo con este nuevo enfoque de cargar todas las declaraciones de antemano. Así que, redoble de tambores, veamos los tiempos. Como puedes ver, incluso solo mirando los números, hay una gran mejora allí. Obtenemos tiempos de compilación de un solo dígito. Mirando un gráfico, tal vez se haga más claro que la mejora en el rendimiento es bastante dramática. Estamos hablando de una mejora de tres veces en el rendimiento. Cuando vimos estos números, realmente nos alegramos de que nuestra teoría funcionara y nuestras expectativas se cumplieran e incluso superaran en algunos aspectos.

Entonces, ¿qué nos depara el futuro? Bueno, esperamos obtener esta característica en TypeScript pronto. No sabemos exactamente cuándo, pero esperamos que suceda en los próximos seis meses. La otra pregunta que suelo recibir cuando hablo sobre esta característica es si esto puede ayudar en una configuración de proyecto único. Aún no estamos seguros de esto. Hemos realizado algunas experimentaciones, pero todavía hay algunas limitaciones que deben resolverse en el compilador de TypeScript primero. Veremos si podemos ayudar con eso también. ¿Puede esto volverse aún más rápido? Utilizamos la base del compilador de TypeScript para implementar nuestro propio emisor de declaraciones. Hay espacio para que otras herramientas sean mucho más rápidas, al igual que existe un ecosistema de emisores de JavaScript. Con suerte, habrá un ecosistema de emisores de declaraciones de TypeScript y eso hará que las cosas sean aún más rápidas.

Me gustaría agradecer a todas las personas involucradas de Google, Hannah Joo y Yann Kuehler, de Microsoft Daniel Rosenwasser, Jake Bailey y Ryan Kavanagh, y de Bloomberg, Rob Palmer, Thomas Chatwin y Ashley Claymore. También un agradecimiento especial al equipo de Flow, que implementó una característica muy similar hace un tiempo y que fue definitivamente una fuente de inspiración para nosotros. Muchas gracias por escuchar y estoy listo para responder cualquier pregunta en el chat. Gracias. Microsoft Mechanics www.microsoft.com www.microsoft.com www.facebook.com www.youtube.com

www.youtube.com