Ejecutar TypeScript Nativamente en Node.js

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Imagina la conveniencia de ejecutar archivos TypeScript directamente con Node.js usando `node file.ts`. Hace solo unos años, este concepto parecía un sueño lejano. Hoy, se presenta como una característica experimental emocionante. Esta charla narra el viaje de transformar este sueño en una realidad.

This talk has been presented at JSNation 2025, check out the latest edition of this JavaScript Conference.

Marco Ippolito
Marco Ippolito
28 min
12 Jun, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Discusión sobre la adopción de TypeScript en Node.js, la popularidad de TypeScript, los desafíos en la integración de TypeScript con Node.js debido a las diferencias de versionado, la introducción de strip types para eliminar la sintaxis no JavaScript, el aprovechamiento de la biblioteca SWC a través de Amaro para una ejecución de código eficiente, el soporte de Node.js para TypeScript con strip types experimental, habilitando transform types y source maps por defecto, la evolución de TypeScript con nuevas banderas para la verificación de tipos, la evaluación de código ESM de TypeScript en Node, problemas con la ambigüedad de sintaxis entre TypeScript y JavaScript, la colaboración entre los equipos de Node.js y TypeScript, recomendaciones sobre el uso de TypeStripping para proyectos de producción, comparación del rendimiento entre TS Node y Node para TypeScripting, manejo de definiciones de tipos y verificación en tiempo de ejecución en TypeScript usando Zod.

1. Analyzing TypeScript Support in Node.js

Short description:

Discusión sobre la adopción de TypeScript en Node.js, la popularidad de TypeScript y los desafíos en la integración de TypeScript con Node.js debido a las diferencias de versionado.

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.

2. Challenges with TypeScript Integration in Node.js

Short description:

Discusión sobre los desafíos con la integración de TypeScript en Node.js, superando el requisito de source map y la introducción de strip types para TypeScript en Node.js.

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.

3. Understanding Strip Types in TypeScript

Short description:

Explorando el concepto de strip types en TypeScript, que implica eliminar la sintaxis que no es de JavaScript y evitar la necesidad de source maps. El type stripping elimina los tipos de TypeScript, centrándose en la ejecución de código JavaScript sin verificación de tipos en tiempo de ejecución.

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.

4. Implementing Type Stripping with Amaro in Node.js

Short description:

Explorando el enfoque de type stripping en TypeScript, que elimina elementos específicos de TypeScript, asegurando estabilidad a través de las versiones de TypeScript, y aprovechando la biblioteca SWC a través del envoltorio Amaro en Node.js para una ejecución de código eficiente.

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.

5. Enhancements in TypeScript Handling in Node.js

Short description:

Explorando el soporte de Node.js para TypeScript con la introducción de tipos de eliminación experimentales en Node 22.6, luego habilitados por defecto en Node 23. Existen limitaciones debido a la naturaleza del type stripping, que solo admite características específicas de sintaxis de TypeScript que requieren transformación, excluyendo elementos como enums.

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.

6. Advanced Features and Syntax Handling in Node.js

Short description:

Introducción de tipos de transformación experimentales para soportar características que requieren transformación y habilitar mapas de origen por defecto en Node.js. Evitar características de TypeScript que necesitan transformación y nivelación descendente para características de JavaScript no soportadas. Habilitar la palabra clave 'using' en Node 24 y especificar la necesidad de usar la extensión TypeScript durante las importaciones.

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.

7. Evolving TypeScript Usage in Node.js

Short description:

Evolución de TypeScript: Nueva bandera en 5.7 permite cambiar extensiones .ts a .js en tiempo de compilación para verificación de tipos. Uso obligatorio de la palabra clave 'type' para importar tipos. Evitar módulos Node de TypeScript debido a preocupaciones del ecosistema.

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.

8. TypeScript ESM Code Evaluation in Node.js

Short description:

Cumplimiento sin TypeScript en módulos Node, banderas clave para type stripping. Implementación de la evaluación de código TypeScript ESM en Node usando la nueva bandera 'dash --input type'.

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.

9. Syntax Ambiguity and TypeScript Stability

Short description:

Problemas con la ambigüedad de sintaxis de TypeScript y JavaScript, TypeScript no es un verdadero superconjunto de JavaScript, próxima corrección de errores y estabilidad de TypeScript en node 24.

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.

QnA

TypeScript Stability and Collaboration

Short description:

Discusión sobre la estabilidad de TypeScript y su adopción generalizada, colaboración entre los equipos de Node.js y TypeScript para el desarrollo y aprobación de características.

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.

Recomendaciones de TypeStripping y Uso en Producción

Short description:

Recomendaciones sobre el uso de TypeStripping para código TypeScript basado en el caso de uso y consideraciones de tiempo de inicio. Fomento para comenzar a usar TypeStripping en proyectos de producción debido a su amplia adopción y estabilidad.

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.

Enums Impact and TS Node Performance Comparison

Short description:

Discusión sobre el impacto potencial en enums en TypeScript y la existencia de una propuesta para incorporar enums en JavaScript. Comparación de rendimiento entre TS Node y Node para TypeScripting, desaconsejando TS Node debido a problemas internos de Node.

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.

TypeScript Development Experience and Versioning

Short description:

Discusión sobre la experiencia del desarrollador de TypeScript con el Node test runner, cobertura en Node test, consultas de rendimiento y el enfoque de versionado semántico de TypeScript.

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.

Node Team Collaboration and TypeScript Challenges

Short description:

Discusión sobre colaboraciones con Bun o Dino, ejecución de código TypeScript en Node, desafíos en la ejecución de aplicaciones TypeScript válidas directamente en Node, y construcción de consenso en la implementación de TypeScript.

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.

Runtime Checking in TypeScript with Zod

Short description:

Discusión sobre el manejo de definiciones de tipo y verificación en tiempo de ejecución en TypeScript usando Zod y la garantía de una implementación exitosa, seguida de agradecimientos por la discusión e implementación de una característica valiosa de Node.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Los tipos más útiles de React
React Day Berlin 2023React Day Berlin 2023
21 min
Los tipos más útiles de React
Top Content
Today's Talk focuses on React's best types and JSX. It covers the types of JSX and React components, including React.fc and React.reactnode. The discussion also explores JSX intrinsic elements and react.component props, highlighting their differences and use cases. The Talk concludes with insights on using React.componentType and passing components, as well as utilizing the react.element ref type for external libraries like React-Select.
TypeScript y React: Secretos de un matrimonio feliz
React Advanced 2022React Advanced 2022
21 min
TypeScript y React: Secretos de un matrimonio feliz
Top Content
React and TypeScript have a strong relationship, with TypeScript offering benefits like better type checking and contract enforcement. Failing early and failing hard is important in software development to catch errors and debug effectively. TypeScript provides early detection of errors and ensures data accuracy in components and hooks. It offers superior type safety but can become complex as the codebase grows. Using union types in props can resolve errors and address dependencies. Dynamic communication and type contracts can be achieved through generics. Understanding React's built-in types and hooks like useState and useRef is crucial for leveraging their functionality.
Es una jungla ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta Node_Modules?
Node Congress 2022Node Congress 2022
26 min
Es una jungla ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta Node_Modules?
Top Content
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
Haciendo Magia: Construyendo un Marco de Trabajo Primero-TypeScript
TypeScript Congress 2023TypeScript Congress 2023
31 min
Haciendo Magia: Construyendo un Marco de Trabajo Primero-TypeScript
Top Content
Daniel Rowe discusses building a TypeScript-first framework at TypeScript Congress and shares his involvement in various projects. Nuxt is a progressive framework built on Vue.js, aiming to reduce friction and distraction for developers. It leverages TypeScript for inference and aims to be the source of truth for projects. Nuxt provides type safety and extensibility through integration with TypeScript. Migrating to TypeScript offers long-term maintenance benefits and can uncover hidden bugs. Nuxt focuses on improving existing tools and finds inspiration in frameworks like TRPC.
Cargadores ESM: Mejorando la carga de módulos en Node.js
JSNation 2023JSNation 2023
22 min
Cargadores ESM: Mejorando la carga de módulos en Node.js
Top Content
ESM Loaders enhance module loading in Node.js by resolving URLs and reading files from the disk. Module loaders can override modules and change how they are found. Enhancing the loading phase involves loading directly from HTTP and loading TypeScript code without building it. The loader in the module URL handles URL resolution and uses fetch to fetch the source code. Loaders can be chained together to load from different sources, transform source code, and resolve URLs differently. The future of module loading enhancements is promising and simple to use.
Hacia una Biblioteca Estándar para Runtimes de JavaScript
Node Congress 2022Node Congress 2022
34 min
Hacia una Biblioteca Estándar para Runtimes de JavaScript
Top Content
There is a need for a standard library of APIs for JavaScript runtimes, as there are currently multiple ways to perform fundamental tasks like base64 encoding. JavaScript runtimes have historically lacked a standard library, causing friction and difficulty for developers. The idea of a small core has both benefits and drawbacks, with some runtimes abusing it to limit innovation. There is a misalignment between Node and web browsers in terms of functionality and API standards. The proposal is to involve browser developers in conversations about API standardization and to create a common standard library for JavaScript runtimes.

Workshops on related topic

React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.
Dominando conceptos avanzados en TypeScript
React Summit US 2023React Summit US 2023
132 min
Dominando conceptos avanzados en TypeScript
Top Content
Featured WorkshopFree
Jiri Lojda
Jiri Lojda
TypeScript no es solo tipos e interfaces. Únete a esta masterclass para dominar características más avanzadas de TypeScript que harán tu código a prueba de balas. Cubriremos tipos condicionales y notación de inferencia, cadenas de plantillas y cómo mapear sobre tipos de unión y propiedades de objetos/arrays. Cada tema se demostrará en una aplicación de muestra que se escribió con tipos básicos o sin tipos en absoluto y juntos mejoraremos el código para que te familiarices más con cada característica y puedas llevar este nuevo conocimiento directamente a tus proyectos.
Aprenderás:- - ¿Qué son los tipos condicionales y la notación de inferencia?- ¿Qué son las cadenas de plantillas?- Cómo mapear sobre tipos de unión y propiedades de objetos/arrays.
Consejos y Trucos Profundos de TypeScript
Node Congress 2024Node Congress 2024
83 min
Consejos y Trucos Profundos de TypeScript
Top Content
Featured Workshop
Josh Goldberg
Josh Goldberg
TypeScript tiene un sistema de tipos poderoso con todo tipo de características sofisticadas para representar estados de JavaScript salvajes y extravagantes. Pero la sintaxis para hacerlo no siempre es sencilla, y los mensajes de error no siempre son precisos al decirte qué está mal. Vamos a profundizar en cómo funcionan muchas de las características más poderosas de TypeScript, qué tipos de problemas del mundo real resuelven, y cómo dominar el sistema de tipos para que puedas escribir código TypeScript verdaderamente excelente.
Mejores Prácticas y Consejos Avanzados de TypeScript para Desarrolladores de React
React Advanced 2022React Advanced 2022
148 min
Mejores Prácticas y Consejos Avanzados de TypeScript para Desarrolladores de React
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
¿Eres un desarrollador de React tratando de obtener los máximos beneficios de TypeScript? Entonces esta es la masterclass para ti.En esta masterclass interactiva, comenzaremos desde lo básico y examinaremos los pros y contras de las diferentes formas en que puedes declarar componentes de React usando TypeScript. Después de eso, pasaremos a conceptos más avanzados donde iremos más allá de la configuración estricta de TypeScript. Aprenderás cuándo usar tipos como any, unknown y never. Exploraremos el uso de predicados de tipo, guardias y comprobación exhaustiva. Aprenderás sobre los tipos mapeados incorporados, así como cómo crear tus propias utilidades de mapa de tipo nuevo. Y comenzaremos a programar en el sistema de tipos de TypeScript usando tipos condicionales e inferencia de tipos.
Masterclass de Node.js
Node Congress 2023Node Congress 2023
109 min
Masterclass de Node.js
Top Content
Workshop
Matteo Collina
Matteo Collina
¿Alguna vez has tenido dificultades para diseñar y estructurar tus aplicaciones Node.js? Construir aplicaciones que estén bien organizadas, sean probables y extensibles no siempre es fácil. A menudo puede resultar ser mucho más complicado de lo que esperas. En este evento en vivo, Matteo te mostrará cómo construye aplicaciones Node.js desde cero. Aprenderás cómo aborda el diseño de aplicaciones y las filosofías que aplica para crear aplicaciones modulares, mantenibles y efectivas.

Nivel: intermedio
Construir y Desplegar un Backend Con Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Construir y Desplegar un Backend Con Fastify & Platformatic
Top Content
WorkshopFree
Matteo Collina
Matteo Collina
Platformatic te permite desarrollar rápidamente GraphQL y REST APIs con un esfuerzo mínimo. La mejor parte es que también te permite desatar todo el potencial de Node.js y Fastify siempre que lo necesites. Puedes personalizar completamente una aplicación de Platformatic escribiendo tus propias características y plugins adicionales. En la masterclass, cubriremos tanto nuestros módulos de Open Source como nuestra oferta en la Nube:- Platformatic OSS (open-source software) — Herramientas y bibliotecas para construir rápidamente aplicaciones robustas con Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (actualmente en beta) — Nuestra plataforma de alojamiento que incluye características como aplicaciones de vista previa, métricas integradas e integración con tu flujo de Git (https://platformatic.dev/). 
En esta masterclass aprenderás cómo desarrollar APIs con Fastify y desplegarlas en la Platformatic Cloud.