Node.js agrega soporte experimental para TypeScript

Módulo: se agrega --experimental-strip-types

• Es posible ejecutar archivos TypeScript en Node.js

  • Al establecer la bandera --experimental-strip-types, se pueden ejecutar archivos TypeScript
  • Node.js transforma el código fuente TypeScript en código fuente JavaScript
  • Durante la transformación no se realiza verificación de tipos; los tipos se eliminan

• Motivación

  • Es importante permitir ejecutar archivos TypeScript sin dependencias externas ni loaders
  • Se busca que los usuarios puedan ejecutar node foo.ts

• Qué significa el type stripping

  • El type stripping consiste en eliminar todos los tipos y convertir la entrada en un módulo JavaScript
  • Ejemplo: const foo: string = "foo"; se transforma en const foo = "foo";

• Por qué se eligió @swc/wasm-typescript

  • Por su simplicidad
  • Otras herramientas requieren agregar Rust o Go, pero @swc/wasm-typescript solo necesita un paquete pequeño con archivos wasm y js
  • También se usa en Deno, por lo que es confiable

• Limitaciones

  • Funciones exclusivas de TypeScript como enum y namespaces no se transforman
  • No se admiten imports sin extensión

• Planes a futuro

  • Podría implementarse en la capa nativa
  • Se podría agregar soporte para source maps

Resumen de GN⁺

• Explica una nueva función para permitir ejecutar archivos TypeScript en Node.js
• Permite ejecutar archivos TypeScript transformándolos a JavaScript, sin realizar verificación de tipos
• Esto simplifica el entorno de desarrollo al permitir que los usuarios ejecuten archivos TypeScript sin dependencias externas
• Esta función fue implementada usando @swc/wasm-typescript, y también se está considerando una implementación en la capa nativa a futuro
• Puede ser útil para proyectos que mezclan TypeScript y JavaScript.

[GN⁺]

Opiniones en Hacker News

• Eliminar los tipos de TypeScript no es posible sin la gramática de TypeScript. Quitar tipos no es una tarea a nivel de tokens, y la gramática de TypeScript sigue cambiando

  • Por ejemplo, foo < bar & baz > ( x ) se interpretaba de manera distinta en TypeScript 1.5
  • Para usar nuevas funciones de TypeScript, habrá que compilar a JS o mantener Node actualizado a la última versión
  • Para quienes usan lanzamientos LTS de Node, esto puede ser un compromiso difícil

• Si Node.js pudiera ejecutar archivos TypeScript directamente, el compilador de TypeScript ya no tendría que quitar los tipos y convertirlos a JavaScript

  • Esto es similar a la situación de Python
  • En Python existen varios verificadores de tipos, y todos usan la misma sintaxis de type hints pero aplican significados distintos
  • En JavaScript, TypeScript se ha convertido en el único verificador de tipos popular
  • En Python, algunas personas usan los type hints como si fueran comentarios
  • Si Node.js soporta ignorar tipos, eso también podría ser posible en JavaScript

• Si esta función se vuelve el valor predeterminado, me pregunto cómo reaccionará el ecosistema de NPM

  • Al publicar módulos de NPM, surge la duda de si seguir construyendo versiones CJS y EJS, o simplemente agregar engine: nodejs >= 25 a package.json y omitir el paso de build
  • Personalmente, espero que los módulos de NPM escritos en TS dejen de ofrecer dist/.cjs
  • Omitir el paso de build será tentador para quienes contribuyen en NPM
  • Esto podría generar un efecto dominó en el ecosistema de NPM
  • Si Node.js ofrece esta función sin una bandera experimental, es de esperarse que todos los consumidores acepten archivos TS
  • Esto también podría forzar a Firefox y Safari a aceptar archivos TS
  • Personalmente, me parece bien que el compilador de JS descarte las anotaciones de tipos de TS
  • Si Node acepta archivos .ts, se puede eliminar el paso de transcompilación

• Sería una gran ventaja si Node pudiera inspeccionar tipos en JS

  • En Python existen herramientas como pydantic, que inspeccionan tipos y generan validaciones
  • Esto permite validación de tipos, validación de datos en tiempo de ejecución, generación de APIs y generación de documentación de APIs con una sola notación estándar
  • Actualmente en JS se necesitan herramientas como zod

• La experiencia de desarrollo (DX) de Bun no tiene precedentes en esta área y cubre la mayoría de los casos de uso

  • En Node no se puede configurar para que no exija extensiones al hacer import, ni se puede configurar tsc para que agregue automáticamente extensiones .js
  • El soporte nativo de TypeScript podría resolver esto, pero será difícil igualar la experiencia de usuario o el rendimiento de Bun

• Disfruto mucho TypeScript y he deseado desde hace tiempo un runtime de TypeScript

  • Dejé Java porque quería un sistema de tipos con más funciones y tipado gradual
  • A pesar de las desventajas del ecosistema npm, usar librerías se siente menos pesado y más divertido
  • Rust está en otro extremo del espectro de lenguajes, pero ofrece una sensación parecida
  • JIT no era el término correcto; lo que quería decir eran las diferencias de tiempo de arranque y de ejecución entre JVM y V8

• Mi función favorita de deno está llegando directamente a Node

  • Me entusiasma mucho poder quitar tipos sin instalar esbuild
  • Últimamente he preferido Python, pero TypeScript es mejor que Python en cuanto a tipos
  • Los scripts grandes se benefician mucho más cuando tienen tipos

• Ha sido un mes muy importante para Node

  • En v22.5.0 agregaron node:sqlite, y ahora llega el soporte para TypeScript
  • Me gusta la dirección que está tomando Node

• Soy el autor del PR, AMA

• Hace mucho tiempo empecé a usar Node.js para trabajo de backend, y ofrecía muchas ventajas frente a PHP

  • Node era algo engorroso y había que ensamblarlo para convertirlo en el lenguaje que uno quería
  • Empecé a usar Golang, y gracias a la seguridad de tipos programar se volvió más fácil
  • TypeScript es una buena opción, pero no deja de ser otro añadido más
  • La gran ventaja de usar Node es la velocidad para hacer prototipos, y usar TypeScript puede contrarrestar esa ventaja