Ejecutar TypeScript Nativamente en Node.js

Sí, así que hoy hablaremos sobre cómo hicimos posible ejecutar TypeScript directamente en Node.js y por qué, y por qué no tal vez CoffeeScript o Flow, o como, ¿por qué TypeScript? Así que no importa. Así que comencemos desde el principio. Así que si estuviste en la masterclass hoy, hablamos sobre el estado de JS. Y tengo una pieza de historia muy interesante para ti. Este es el Estado de JS 2016 prehistórico. Y podemos ver que TypeScript estaba justo al principio. Podemos ver CoffeeScript y ClosureScript, muchas tecnologías que eran mucho más populares que TypeScript, pero luego desaparecieron.

TypeScript ha ganado la batalla del superset de JavaScript. Se considera uno de los lenguajes de programación más populares según GitHub. Está en aumento. Y JavaScript está bajando un poco. Y también es uno de los lenguajes de más rápido crecimiento en 2024. Así que si vas al repositorio de Node.js, abres un issue, ¿por qué no soportas CoffeeScript o Flow? Esta es la razón por la cual. Porque la gente lo hizo. Así que fue divertido.

Así que como proyecto de Node.js, tuvimos muchos problemas. Por favor, soporten TypeScript. Por favor, queremos TypeScript. Queremos poder ejecutar Node.file.js, lo que sea. Así que hubo años de discusiones, años de cómo podemos hacer eso. Así que hay algunos desafíos para este soporte de TypeScript. El primero es que TypeScript no tiene una especificación. TypeScript es la implementación es la especificación. Y no sigue SEMVer. Así que cada vez que lanza un nuevo minor, puede tener cambios disruptivos. Y eso es un problema porque Node.js tiene garantías de estabilidad muy estrictas. Una versión de Node.js dura alrededor de tres años, mientras que TypeScript avanza mucho, mucho más rápido. Así que tomar TypeScript como una biblioteca, ponerlo dentro de Node, sí, es fácil. Pero no es lo que quieres. No quieres cambios disruptivos cada tres meses.

Como cuando tu despliegue se rompe un viernes. No quieres eso. Por eso no podíamos tomar TypeScript como una biblioteca directamente e integrarlo en Node. Otro problema era que hasta este año, cuando lanzamos el ESM requerido en todas las líneas de lanzamiento de Node.js, la interoperabilidad seguía siendo un problema, era problemática. Ahora ese problema ha sido resuelto, así que puedes requerir módulos ESM. Y son totalmente interoperables.

TypeScript requiere source map o tal vez eso pensábamos, que TypeScript requiere source map. Esto no es completamente cierto porque encontramos una manera de ejecutar TypeScript sin source map. Pero a la gente no le gustaba tener source map porque son una gran penalización de rendimiento. Son propensos a errores. Es muy difícil implementarlos correctamente. Y finalmente, ningún campeón. Nadie quería hacer el trabajo de implementarlo, especialmente como voluntario.

Esto era mucho trabajo. Pero una mañana del año pasado, me desperté y abrí este PR, que es el PR más votado en el repositorio de Node. Y es añadir strip types experimental. Así que esta fue la primera pieza para ejecutar TypeScript nativamente en Node.js. Lo hice solo porque lo sentí. Como, sin una razón real. Solo quería demostrar que era posible ejecutar TypeScript en Node. Y este PR se integró en 20 días, lo cual fue increíble en ese momento.

Entonces, ¿qué son los strip types? ¿Qué significa? ¿Y es realmente ejecutar TypeScript? ¿Qué está pasando? Así que este es un pequeño fragmento de código TypeScript. Imagina que tomamos una goma y comenzamos a borrar toda la sintaxis que no es JavaScript. Así que las interfaces no son JavaScript. Así que podemos eliminarlas. Los tipos no son JavaScript. Así que podemos eliminarlos. OK, esto es JavaScript, ¿verdad? Y podemos ejecutar este fragmento de código. Así que esencialmente, esto es type stripping. Pero hemos cambiado la forma de nuestro código. ¿Hay una manera de preservar las ubicaciones? Como puedes ver, la longitud del archivo ha cambiado. La ubicación en la que la función está dentro del archivo ha cambiado. Esto requiere source maps. Y no queremos source maps. No nos gustan los source maps. Entonces, ¿hay una manera de hacer esto? Mientras trabajaba en la función, alguien sugirió, ¿por qué no reemplazas la sintaxis eliminada con espacio en blanco? Fue como, phew. Sí, y hacemos eso. Así que la salida se verá así. Y esto funciona porque no necesitas source maps. Así que la ubicación dentro del archivo coincide uno a uno. Entonces, ¿qué es el type stripping? El type stripping es eliminar los tipos de TypeScript. Todo lo que se pueda borrar que no sea JavaScript será borrado. No realizará verificación de tipos. Así que la verificación de tipos es algo que solo TypeScript puede hacer como biblioteca. No hay otras implementaciones porque no hay especificación. Así que solo TypeScript puede hacerlo. Y generalmente no quieres realizar la verificación de tipos en tiempo de ejecución. Es muy costoso. Va a ralentizar tu desarrollo. También tienes tu IDE que te dirá cuando estás escribiendo algo que no deberías escribir. Y generalmente realizas la verificación de tipos en una pipeline o como un commit hook.

Así que no es algo que ejecutes rápidamente. Así que todavía pensamos que deberías instalar TypeScript para realizar la verificación de tipos. No queremos poner TypeScript en el runtime. No requiere tsconfig porque simplemente eliminamos todo lo que es específico de TypeScript. Así que no hay nada que configurar. Solo elimina tipos en línea. Y veremos un poco más adelante qué significa tipos en línea.

Así que no todo se puede eliminar porque hay alguna sintaxis que no... afecta al runtime. Así que no se puede eliminar. No requiere source maps, que es la mayor ventaja, en mi opinión, de este enfoque. Y es estable a través de las versiones de TypeScript porque TypeScript no lanza nueva sintaxis en actualizaciones menores, solo en mayores. Así que podemos ser consistentes con TypeScript. Y siempre que haya una nueva sintaxis, podemos actualizar el transpiler en una versión mayor de Node.js.

Así que no hay cambios disruptivos, no hay viernes pasados depurando tus pipelines. Y eso es muy genial. Bien, ¿cómo lo hicimos? Creamos una biblioteca llamada Amaro. Amaro significa amargo en italiano porque todo el asunto fue un poco amargo. Pero sí, puedes instalar Amaro. Es un envoltorio alrededor de SWC. Así que está usando SWC por debajo. SWC, es muy popular. Es utilizado por RSpark, Deno. Está probado en batalla, así que puedes confiar en que SWC funciona bien. Y es una versión personalizada de SWC solo para Node.

Así que con Node 22.6, introdujimos esta bandera, experimental strip types, que te permite ejecutar TypeScript. En Node 23, la habilitamos por defecto. Así que puedes simplemente ejecutar node file.ts, y funciona. Tiene algunas limitaciones debido a la naturaleza del type stripping. Solo puedes... Tienes una sintaxis limitada de TypeScript que es compatible. Así que solo las características de TypeScript que requieren transformación no son compatibles.

Un ejemplo son tus queridos enums. Realmente no me gustan los enums. Realmente no me gustan los enums. Pero los enums no pueden ser eliminados de manera segura porque afectan al runtime porque exportan valor. Así que no pueden ser eliminados. Los namespaces que exportan valores no pueden ser eliminados. Así que esta sintaxis necesita ser transformada en JavaScript. Así que los enums, por ejemplo, se transpilan en esta monstruosidad justo aquí. Puedes ver. Así que si te gustan los enums, esto es lo que obtienes. No queremos generación de código en tiempo de ejecución. Así que decidimos no soportarlos.

Además, TypeScript, estuvieron de acuerdo con nosotros. Y crearon una nueva bandera llamada erasable syntax only que no te permitirá usar sintaxis como enums u otros namespaces con propiedades de parámetros de código en tiempo de ejecución. Así que todo lo que no pueda ser eliminado, usa esta bandera tsconfig y será prohibido. Así que en Node 23.8 añadimos soporte para namespaces solo de tipo. Antes solo prohibíamos los namespaces. Ahora puedes usar namespaces, pero solo si exportan tipo. Así que son eliminables.

Sabemos que a mucha gente le gustan los enums. Quieren usar enums. Así que creamos una nueva bandera llamada experimental transform types que soporta todas las características que requieren transformación. Esto siempre estará marcado, nunca se desmarcará y probablemente siempre permanecerá en estado experimental porque no se puede confiar completamente en ello, pero puedes usarlo mientras haces la transición al type stripping.

Además, los mapas de origen están habilitados por defecto porque si cambias, generas código JavaScript entonces necesitas mapas de origen y tienes toda la penalización de rendimiento y problemas de los que hablamos antes. Como dije, no hay características de TypeScript que requieran transformación. No hay nivelación descendente. ¿Qué es la nivelación descendente? Soportar características de JavaScript que aún no están en el motor de JavaScript.

Así que un ejemplo es la palabra clave using en la propuesta de gestión de recursos explícita. Así que TypeScript en el pasado haría un polyfill de esta sintaxis para permitirte usarla aunque no esté soportada por el motor de JavaScript. Así que ignoramos esta sintaxis. Si está soportada por el motor de JavaScript, puedes ejecutarla. Si no está soportada, tendrás una excepción en tiempo de ejecución. Esta palabra clave using ahora está habilitada en Node 24, así que puedes usarla, pero no en Node 22. Necesitas ser explícito con el... Cuando importas el archivo, necesitas usar la extensión TypeScript en lugar de la extensión JS.

Así que en el pasado, el equipo de TypeScript era muy... Sentía fuertemente no usar las extensiones .ts aunque el archivo fuera TypeScript porque el resultado sería que necesitaba reescribir las extensiones en tiempo de construcción lo cual no es 100% preciso. Ya podías, con esta bandera, permitir importar esta extensión. Usar la extensión .ts, pero si intentas compilar, lanzaría un error. TypeScript no puede compilar porque necesitaría reescribir esta extensión. Pero... Así que usarías el no emit o solo declaración de emisión junto con esta bandera para poder verificar tipos. Así que es solo verificación de tipos. Pero en TypeScript 5.7, una nueva bandera permite a los usuarios reescribir la extensión para que puedas usar la extensión .ts y en tiempo de compilación, se cambiará a la extensión .js porque el archivo es transpilado. Y se llama rewrite relative import extension, así que puedes escribir... Puedes usar la extensión .ts que también es compatible con Node de lo contrario Node no permitirá usar la extensión .js si el archivo es TypeScript porque en tiempo de ejecución, ese archivo es un archivo TypeScript. Así que necesitas usar esta bandera. También necesitas usar la palabra clave type si estás importando tipos porque si... Tomemos este ejemplo. Así que el de arriba es correcto. Siempre que estés importando un tipo, necesitas usar la palabra clave type porque un nodo borrará toda la sintaxis borrable y los tipos son una pieza de sintaxis borrable. Así que si usas la palabra clave type, Node también borrará la importación en sí porque es solo un tipo y no afecta al tiempo de ejecución. Pero si no usas la palabra clave type, Node pensará que esto es algún código que estás ejecutando en tiempo de ejecución y no lo borrará pero la exportación será borrada, por lo que tendrás un error en tiempo de ejecución. Esto es impuesto por la sintaxis del módulo verbatim de TypeScript y desde la última versión de TypeScript está habilitado por defecto así que tendrás... Como TypeScript se enojará mucho contigo si no usas la palabra clave type. Y finalmente, lo más odiado probablemente es ejecutar módulos Node de TypeScript. Tuvimos que desalentar artificialmente a los usuarios de ejecutar módulos Node de TypeScript. Siempre que lo intentes, obtienes este error muy largo y módulos Node no soportados type stripping. La razón por la que esto fue solicitado por el equipo de TypeScript, no quieren que el ecosistema comience a publicar paquetes NPM con TypeScript.

Quizás podamos eliminar esta limitación en el futuro pero por ahora, necesitamos cumplir. Así que, no TS en módulos Node. Este es el TS comb que deberías estar usando con Node para type stripping. Si quieres tomar una foto, te doy 10 segundos. Estas son todas las banderas de las que hablamos. Así que, solo sintaxis borrable, sintaxis de módulo verbatim, reescribir extensiones de importación relativas, y básicamente eso es todo. Estas tres nuevas banderas.

Tengo tres minutos así que iré muy rápido pero este es un dato curioso súper genial. Tuve que implementar la evaluación de código TypeScript en Node. Este es un fragmento de código. Espero que sea lo suficientemente grande. Es un código ESM, como puedes ver, importar desde util y también es TypeScript porque const foo es un string. Esto es TypeScript ESM. ¿Cómo detecta Node que esto es TypeScript ESM? Primero, intenta compilarlo como un módulo common JS. No es un módulo common JS así que eso va a fallar. Luego intenta compilarlo como un módulo ESM, pero eso no es un módulo ESM, es ESM TypeScript. Así que, eso también va a fallar. Así que, intentamos eliminar los tipos. Eliminamos los tipos de TypeScript. Así que, tenemos una cadena que se ve así con un agujero en el medio porque hemos eliminado los tipos de TypeScript. Así que, si eso falla, significa que probablemente tienes errores de sintaxis. Así que, volvemos a lanzar el error original con un mensaje de error enriquecido. De lo contrario, intentamos nuevamente ejecutarlo como un common JS. No es common JS de nuevo. Volvemos a intentar como un módulo ESM y finalmente podemos ejecutar este fragmento de código.

Como puedes ver, es muy costoso detectar la sintaxis. Por eso creamos una nueva bandera llamada dash dash input type. Puedes elegir module TypeScript o common JS TypeScript. Así que, node sabrá qué tipo de sintaxis estás usando, y así se salta todos estos pasos, elimina los tipos y lo ejecuta. Pero, ¿qué hay de esto? Así que, este es un código TypeScript, ¿verdad? ¿Lo es? Bien, intentemos evaluar este fragmento de código.

Pero, ¿qué pasa con esto? Entonces, este es un código TypeScript, ¿verdad? ¿Lo es? Bien, intentemos evaluar este fragmento de código. Y el resultado es falso. ¿Qué demonios? ¿Por qué falso? ¿Qué está pasando? Y si lo intentas en el navegador, también obtenemos falso. De nuevo, ¿qué está pasando? ¿Eh? Sí, esta es sintaxis de JavaScript. Esto no es TypeScript. Esto es, bueno, también es TypeScript, pero también es JavaScript. Es una función foo, así que fetch es una función global. Es menor que un objeto global. Es mayor que una cadena y se evalúa como falso. Así que, esta es una ambigüedad de sintaxis loca.

Si intentamos ejecutar esto en el playground de TypeScript, lo evaluará como un fetch, no como falso, lo cual es inconsistente. Esto significa que si intentas ejecutar esto en nodes con el tipo de entrada como TypeScript, se evaluará como fetch. Pero si no lo especificas, se evaluará como falso. Por eso TypeScript no es un verdadero superconjunto de JavaScript, por cierto.

Y entonces, ¿cuáles son los próximos pasos? Corrección de errores y conexión en 22 y hacerlo estable. Estamos trabajando en esto. Así que, algún tipo decidió llevar TypeScript al navegador, así que realmente puedes hacer TypeStripping en el navegador con Amaro. No deberías hacerlo, pero es una locura que puedas. Hace unos días, lancé la versión 0.1 de Amaro. Estamos llevando TypeScript estable en node 24. Así que, Amaro necesita ser estable. También eliminamos la advertencia experimental de cada vez que ejecutas TypeScript. Así que, desde node 24, no tendrás una advertencia experimental, así que deberías comenzar a usarlo.

Todavía es experimental, pero probablemente antes de octubre, se volverá estable, tal vez un poco más tarde en octubre. Y finalmente, se retrocederá a node 22. Esto abrirá las puertas a TypeScript en todas partes. Y cuando node 20 llegue al final de su vida útil el próximo año, todas las versiones de node estarán ejecutando TypeScript. Así que, por favor, pruébalo. Para comentarios, puedes ir a este repositorio. Tenemos reuniones semanales con el equipo de TypeScript. Y eso es todo. Gracias.

Sin embargo, quería comenzar simplemente preguntando, ¿cuál fue la inspiración para simplemente eliminar tipos? Parece como una solución mágica para no tener que lidiar con el código fuente. Es como, ¿de dónde vino eso? Entonces, mientras estaba prototipando el soporte experimental de TypeScript, un tipo de Bloomberg también estaba trabajando en TS blank space. Así que, Ashi Claymore. Entonces, él sugirió como, oye, estoy trabajando en esto. Es súper genial. Como, ¿por qué no lo haces? Y yo estaba como, esto es brillante. Hagámoslo. Y lo hicimos. Fantástico.

Y sí, ¿hay ahora más colaboración entre el equipo de Node.js y el equipo de TypeScript para asegurarse de que no te tomen por sorpresa con algo en TypeScript 6 cuando eso llegue? Sí. Cada dos semanas, tenemos una reunión con el equipo de TypeScript. Así que, comenzamos la conversación muy temprano sobre esta característica. Y obtuvimos su aprobación para lanzarla. Al principio, no estaban súper contentos. Pero lo aceptaron. Y ahora, lo apoyan completamente. ¿Pensaron que estabas tratando de robarles el protagonismo o algo así? Sí. Pero la verificación de tipos sigue siendo importante. Es la parte más importante, ¿verdad? Sí, absolutamente.

Bueno, es genial escuchar eso. Oh, tenemos algunas preguntas llegando. Genial. OK. ¿Recomendarías usar TypeStripping para ejecutar código TypeScript ahora? ¿O todavía compilarías primero? Depende de tu caso de uso. Si estás ejecutando, por ejemplo, algo como un servidor HTTP que dura mucho tiempo. Porque tienes un tiempo de inicio incrementado. Porque tienes que transpilar. Entonces, si te importa el tiempo de inicio, sugeriría seguir compilando. Así, tienes JavaScript. Pero si no te importa el tiempo de inicio, definitivamente deberías usarlo. Es estable. Y adelante. Sí, bien. OK.

Una segunda pregunta. Pregunta similar. ¿Recomiendas esto en proyectos de producción? ¿O deberíamos esperar hasta el otoño? Supongo que... Entonces, mencionaste octubre. ¿Es cuando node 24 entra en LTS? Sí. Sí, OK. Sí. Sí. ¿Comenzar a usar esto ahora o esperar hasta... Puedes comenzar a usarlo ahora. Muchas empresas lo están usando. Es como... Tiene una amplia adopción. Así que... Eso es increíble.

Estamos estables. Sigamos adelante. Sí, increíble. OK. ¿Esto va a acabar con los enums en TypeScript? Esa es una forma de verlo. Pero también podrías pensar que tal vez los enums se incorporen en la especificación de JavaScript. Así que... ¿Hay una propuesta para eso? Sí, hay una propuesta. Y es la buena propuesta de enums. Buenos enums. Muy bien. Entonces, si quieres enums, si tú... Bueno, no lo sé. Esta pregunta viene con los dedos cruzados. Con suerte, sí acaba con los enums. Pero si quieres ver enums en JavaScript, en JavaScript, ve a revisar esa propuesta. Ve a apoyar eso. Sí. Increíble.

¿Hay una diferencia de rendimiento entre TS Node o Node haciendo TypeScripting? Obviamente, Node es mucho, mucho, mucho, mucho más rápido. Desalentaría el uso de TS Node porque hace algunos monkey patching de los internos de Node. Y nos causa muchos problemas. Sí. TS Node también me ha causado problemas recientemente. No lo sé. Es como, deja de usar TS Node, diría. Usa esto. Si todavía tienes tus enums ahí, y no tienes cosas no eliminables, TSX es bastante bueno para ese tipo de cosas. Quiero decir, puedes usar dash dash transform types y ejecutará todo. Perfecto.

Oh, esta es una buena pregunta. Y una cercana a mi corazón también. ¿Cómo es la experiencia del desarrollador al usar TypeScript con el Node test runner? Suave. Está bien. Está bien. Absolutamente bien. Sí. Sí, genial. Súper, súper suave. Hice un poco de trabajo en esto yo mismo. Y lo he ignorado por un tiempo.

¿Estamos más cerca de la cobertura en Node test? No sé si sabes esto. Creo que todavía es experimental, pero es lo suficientemente bueno para ser usado. Sí, agradable. Oh, sí. Más preguntas sobre rendimiento y diferencias. Asumo que esta es solo la forma más rápida de hacerlo. ¿Alguna pregunta sobre rendimiento? ¿Type stripping en Node es la forma más rápida? Sí, sí, sí. Agradable. Otra sobre rendimiento. Entonces la pregunta, creo que podrías haber cubierto esto, pero hagámoslo de nuevo. La pregunta es, pensé que TypeScript no tenía un verdadero versionado semántico después de 4.9 viene 5. ¿Es seguro depender de esto? Sí, porque el samver, entonces los cambios disruptivos son más para la comprobación de tipos en lugar de la sintaxis. La sintaxis es estable. Entiendo por qué no siguen samver, porque cada vez que rompen la comprobación de tipos, tendrían que lanzar una versión principal, estaríamos en TypeScript 100 y algo. Pero la sintaxis es estable. Y por eso discutimos con el equipo de TypeScript sobre esto. Correcto. Y solo las versiones principales van a cambiar esa sintaxis. Y porque estás hablando más con ellos, todo eso también estará bien.

Sí. Increíble. ¿Hay alguna colaboración planeada entre el equipo de Node y como Bun o Dino para ejecutar código TypeScript? ¿Hablan con ellos sobre este tipo de cosas? No realmente. Pero si trabajas en Bun o Dino, podemos hablar. Eso es genial. Sí. De acuerdo.

¿En qué punto? ¿Hay una posibilidad, hay un punto en el que será posible ejecutar cualquier aplicación TypeScript válida directamente en Node? Es decir, sin cambiar las declaraciones de entrada, sin eliminar tus enums? No lo creo, porque el subconjunto de sintaxis que decidimos soportar es más pequeño. TypeScript te da mucha configuración, puedes hacer todo tipo de sintaxis impía, como import requiere cosas que no podemos soportar, porque eso requiere transformación, requiere configuración, extensiones, menos imports, muchas cosas que no nos gustan. Nuestra implementación de TypeScript es JavaScript con tipos, y eso es todo. Así que lo que sea que ya estés haciendo en Node, más tipos. Sí, agradable.

Sí, creo que es bastante... Con la bandera en TypeScript, donde puedes decir solo usa las cosas eliminables, creo que ese es un buen subconjunto de TypeScript para recoger y usar. Y te da esas barandillas para asegurarte de que vas a hacer las cosas bien para Node, y que no estás usando enums, que a la mayoría de la gente no parece gustarle. Exactamente. De acuerdo, esto es bueno. Bien. ¿Cuál fue el mayor desafío que tuviste al implementar esto? El mayor desafío fue lograr consenso. Así que no fue técnicamente desafiante, pero lograr consenso para implementar esto, fue salvaje, porque la gente tiene diferentes opiniones. Recibí mucho odio de las redes sociales como, oh no, esto no es TypeScript real, y esto es una tontería, pero luego la gente vio el valor de eliminar tipos, y luego se convirtieron en partidarios, y les gustó. ¿Fue el problema más votado a favor y más votado en contra? No el más votado en contra, pero el más... Agradable. Sí. Eso es bueno. No, quiero decir, eso parece... Eso apunta a un desafío mayor en el trabajo de código abierto en proyectos importantes de todos modos, es el consenso y construir eso entre las personas que quieren estas cosas. Sí. Hay mucho más en la programación que solo programar. Bien.

Estamos viendo que llegan más, pero nos estamos quedando sin tiempo ahora mismo. Así que creo que esta podría ser la última pregunta, pero ¿cómo va a manejar esta forma de ejecutar TypeScript las definiciones de tipo y la verificación en tiempo de ejecución en algo como Zod? ¿Hay algo de qué preocuparse, o estamos bien? Creo que estamos bien. ¿Sí? Sí, creo que está funcionando bien. No veo por qué no funcionaría, pero... Sí, quiero decir, si estás ejecutando... Ahmed, creo, hizo la pregunta. Si estás ejecutando proyectos usando Zod, y tienes problemas con esto, ven y pregunta. Hay una sección de preguntas y respuestas después de esto abajo. Es un buen momento para profundizar más en el tema. Y en esa nota, detendré las preguntas ahí. Pero de nuevo, quiero agradecerte de nuevo, Marco. Es increíble que hayas implementado esto. Creo que es una característica absolutamente brillante para Node, y gracias por hablarnos de ello hoy. Gracias.