Node.js ya permite ejecutar archivos TypeScript sin configuración adicional

• Node.js fue mejorado para poder ejecutar archivos TypeScript directamente
• Ahora es posible ejecutar archivos .ts de inmediato, sin configuración adicional ni transpilar
• Los desarrolladores pueden mejorar su eficiencia de trabajo sin tsconfig.json ni instalar un bundler por separado
• Esta función quedó incorporada oficialmente a partir de Node.js v22.18.0 (LTS)
• Se espera como resultado una frontera más difusa entre el desarrollo con JavaScript y TypeScript

---

Soporte de ejecución directa de TypeScript en Node.js

• Node.js introdujo recientemente en la versión v22.18.0 (LTS) una función que permite ejecutar directamente archivos TypeScript (.ts) sin configuración ni herramientas adicionales
• Antes, para ejecutar código TypeScript se necesitaban transpiladores externos o bundlers como ts-node, esbuild o Babel, pero ahora Node.js reconoce y ejecuta código TypeScript por sí mismo sin esas herramientas
• Gracias a esta función, los desarrolladores pueden ejecutar archivos .ts directamente en Node.js sin archivo de configuración tsconfig.json ni librerías adicionales
• La productividad y la facilidad de desarrollo aumentan considerablemente en prototipado, desarrollo experimental y ejecución de scripts
• Se espera que esto fortalezca la integración entre proyectos JavaScript y TypeScript, y reduzca la barrera de entrada para nuevos desarrolladores

Otros cambios destacados

• esm: implementación de import.meta.main
• fs: mejoras en el manejo de eventos de fs basado en AsyncIterator
• permission: soporte para pasar flags del modelo de permisos al ejecutar subprocesos
• sqlite: se agregó la opción readBigInts
• src/permission: soporte para permission.has(addon)
• url: se agregó la API fileURLToPathBuffer
• watch: se agregó el flag --watch-kill-signal
• worker: el objeto Worker fue mejorado como async disposable

Actualizaciones relacionadas con commits y documentación

• Incluye eliminación de código innecesario, ajustes al entorno de compilación y la cadena de herramientas, y actualización a npm 10.9.3
• Correcciones en indicadores detallados de estabilidad y números RFC en documentación como globals.md, child_process.md y http2
• Se reflejan múltiples pruebas añadidas y correcciones de errores

Archivos de distribución

• Se ofrecen instaladores y binarios para Windows, macOS (Intel/Apple Silicon) y Linux (x64, ARM, PPC, s390x, AIX)
• El código fuente y los archivos completos de la versión pueden descargarse desde la página oficial de distribución de Node.js
• La documentación de la API fue actualizada con base en la versión v22.18.0

[aliveornot]

Ay, qué alivio... ojalá se adopte rápido.

[tested]

Parece que puede estar bien para ejecutar scripts simples, pero para proyectos en producción tiene muchas limitaciones, así que no parece que vaya a usarse mucho.

También hay que ajustar bien las extensiones y las rutas por errores como ERR_MODULE_NOT_FOUND/ERR_UNSUPPORTED_DIR_IMPORT,
y además no se pueden usar funciones que requieren compatibilidad de compilación de TypeScript con configuraciones como emitDecoratorMetadata, como en NestJS, así que...

[kimjeongwonn]

¿Entonces --experimental-strip-types se aplica por defecto?

[click]

Como de todos modos no uso enum, para mí con simplemente eliminar los tipos ya funcionó bastante bien.

[crawler]

¡Se va a volver muchísimo más cómodo!

[honglu]

No puedo contener mi pulgar arriba.

Aunque ya me parecía bastante bueno con la bandera --no-experimental-strip-types.

Parece aún mejor.

[GN⁺]

Comentarios en Hacker News

• Con node:test en Node.js, ahora siento que Node.js ya es una opción predeterminada convincente en la mayoría de los casos. Ejecutar con tsx ya había sido una gran mejora en calidad de vida, pero seguía sin ser algo completo. Con herramientas como zod, ts-rest y trpc, las aserciones de tipos en tiempo de ejecución en los bordes ya se resuelven en gran medida, y hoy en día el desarrollo full-stack con Typescript se ha vuelto realmente fácil
  • Totalmente cierto. Por fin, en 2025, el ecosistema de Node ya se volvió utilizable con la configuración por defecto. Los módulos ESM simplemente funcionan bien tanto en Node como en Typescript, Node puede ejecutar archivos .ts directamente, e incluye un test runner integrado bastante bueno (con soporte para --watch). Los paquetes integrados también han mejorado. En el caso de node:fs/promises, por ejemplo, gracias a top-level await, el trabajo con bucles asíncronos se volvió mucho más fácil. Tomó mucho tiempo convencer a todos de adoptar algo realista, pero ahora de verdad se siente cómodo
  • Estoy muy a favor del soporte directo de Typescript en Node. Últimamente vitest hace cómodas muchas cosas, pero antes había gastado muchísimo tiempo solo configurando entornos de prueba para archivos .ts. Creo que trpc y ts-rest son un tema completamente distinto. Se pueden usar ambos, pero en producción evito trpc porque no puedo ser dueño directo de las URL del API ni gestionar y deprecar de forma natural las URL antiguas. En el caso de ts-rest, normalmente prefiero compartir directamente zod y los tipos para gestionar yo mismo los pares de request/response del API. Y además, cada vez que veo que trpc es claramente una herramienta RPC pero lleva -rest en el nombre, me molesta
  • Voy a estar pendiente de si Sveltr vuelve a migrar su base de código a Typescript en el futuro
  • Me pregunto si esto ejecuta tsx. Aunque elimines los tipos, JSX igual tiene que transformarse a JavaScript, así que esa parte me da curiosidad
  • Yo hace poco me cambié a Python. Estoy mucho más satisfecho porque todo viene integrado y no tengo que depurar varios problemas extraños de un sistema incompleto
• Me ha impresionado mucho el progreso que Node ha mostrado en los últimos años. Me gustó que deno y bun empujaran a Node a hacer mejoras intensivas y significativas. Llevaba un tiempo bastante estancado
  • Me da curiosidad qué mejoras recientes ha tenido Node. La última mejora que sentí realmente importante fue el soporte formal de import/export (aunque no sé si todavía hace falta el hack de .mjs). Estuve algo alejado del ecosistema, así que me gustaría saber qué cambió después de eso
  • No sé si realmente fue así. Viendo los proyectos en los que participé, habrían estado perfectamente bien aunque no existieran deno ni bun. En la práctica, lo único verdaderamente importante son los lanzamientos LTS de Node, y hasta los proyectos nuevos siguen usando Node 20
• Es una pena que Typescript no sea aceptado dentro de node_modules (relacionado: documentación oficial de node.js). Entonces me pregunto qué pasa con las dependencias del proyecto. Escribí una librería para modelos de datos en Typescript y quisiera importarla en mi app tal cual en Typescript. Me pregunto si esta regla aplica solo a paquetes de npm o a todas las dependencias. Aquí hay una oportunidad. Yo hice un runtime basado en golang para ejecutar typescript (más exactamente JS en general), y parece que a sobek, que usa el equipo de grafana, solo le faltaría añadir la función de stripping de tipos. Siento que si aparece un solo runtime que adopte completamente Typescript por defecto, Node.js realmente se revolucionaría. No hacen falta transpilers, ni typescript-go, ni rust (aunque rust sí un poquito 😉), sino un buen parser con un sistema que siga source maps y tipos en modo de depuración. De todos modos, reconocimiento y agradecimiento al equipo de Node y a todos los contribuidores. Se siente que todos vamos detrás de Node por ser el estándar. El API de embedding también es simple y limpio de usar, así que es conveniente incluso al crear ejecutables independientes
  • Ya dejé el mismo comentario antes (referencia). Hay una parte que dice “para desalentar la publicación de paquetes escritos en Typescript en npm”, y yo también lo intenté con paquetes privados, pero no funcionó; a Node ni siquiera le importa el campo private
  • Creo que los paquetes deberían compilarse obligatoriamente a JavaScript antes de publicarse en npm. No veo por qué habría que subir Typescript tal cual a npm
• Issue relacionado Me parece una pena que no haya soporte para stripping de tipos dentro de node_modules
  • Justamente por eso esperaba esta función. Quería poder escribir librerías en Typescript, hacer type-check solo en CI/CD, e importarlas directamente en Node.js
  • Me parece la decisión correcta. Typescript tiene breaking changes con bastante frecuencia. Mientras no se estandarice, creo que el enfoque actual es mejor
• No soy alguien que use muchísimo JS/TS, pero me pregunto si no sería mejor simplemente usar Bun. No todos los proyectos empiezan desde cero, claro, pero Bun me ha parecido un runtime mejor en general. Ejecuta TS desde el inicio, resuelve dependencias mucho más rápido y la experiencia de uso es excelente. Personalmente migré muchos proyectos viejos de Node a Bun, y desde que salió Bun casi no uso Node. Si hay algo que esté entendiendo mal, agradecería que me lo dijeran
  • Usé solo Node durante casi 8 años y hace poco me cambié a Deno. Esa transición tampoco fue fácil, y no porque realmente no funcionara, sino porque daba miedo no saber cuándo podía dejar de funcionar. Node claramente tiene varias cosas mejorables, pero sigue siendo el estándar de facto de la industria. El ecosistema de JS en sí ya es bastante caótico, y muchos desarrolladores están cansados de nuevas build tools, bundlers o runtimes. No creo que Bun todavía haya acumulado suficiente estabilidad o soporte como para resultar realmente convincente. Antes también me pasó que una sola actualización menor de TS me daba problemas durante días
  • No me gusta mucho andar persiguiendo la última tendencia. NodeJS es el runtime con mejor soporte dentro del ecosistema JS. Creo que es mejor ir con la opción predeterminada. Yo suelo elegir tecnologías “aburridas”
  • He intentado cambiarme por completo varias veces desde que salió Bun, pero siempre me topo con algún problema inevitable cuando ya voy como al 90%. En el último intento, algunas librerías no funcionaban porque ciertas funciones de napi no estaban implementadas, y también recuerdo problemas como que se ignoraba recursive en las opciones de opendir. Estoy esperando a que Bun se ponga al día, pero hasta ahora no me parece listo para uso real en proyectos grandes. Las funciones exclusivas de bun también se ven bien de entrada, pero en la práctica se sienten flojas. La documentación tampoco tiene la calidad de la de Node.js
  • Estos son problemas de compatibilidad que tuve al intentar reemplazar Node por Bun.
• Se ignora localAddress en conexiones TCP
• Incompatibilidad con la API de módulos de Node (ejemplo: el proyecto spamscanner no funciona)
• Problemas de race con EventEmitter (solución parcial: con eventemitter2)
• El servidor de desarrollo de Svelte vites a veces se colgaba y había que borrar node_modules e instalar todo otra vez

  • Probé las funciones de TS y del test runner de Node, pero todavía no están al nivel de Bun. Por ahora sigo usando Bun cuando necesito ese tipo de funciones. En el ecosistema de Node aprendí que es mejor combinar herramientas especializadas en vez de apostarlo todo a una sola.

    • Bun.js: para el runtime de Node, y para ejecutar TS y pruebas. He probado de todo: TSX, TS-Node, el propio Node, etc.

    • NPM: para ejecutar scripts de tooling

    • PNPM: para instalar dependencias. (Me parece claramente superior a npm, yarn y bun)

    • Biome.js: para linting. Es mejor que cualquier otra herramienta de linting que haya usado hasta ahora

• Está muy bien que esta mejora se haya implementado solo con “type stripping”, porque no hace falta source maps y en producción termina siendo completamente zero-cost. El equipo de Node lo hizo muy bien
• También está expuesta la función de stripping de tipos (import { stripTypeScriptTypes } from 'node:module'). Para desarrollar una webapp simple sin dependencias de frontend, se puede hacer todo en typescript y al servir los scripts del frontend simplemente quitarles los tipos (proyecto de ejemplo)
• Gracias a este cambio, en mi empresa por fin pudimos migrar a Typescript. Convertimos varios servicios a TS de una sola vez, y otros siguen en proceso. Fue una gran ganancia
• Parece que la forma en que funciona es eliminando la información de tipos. O sea, reduce un paso del transpile, pero no mejora nada en términos de seguridad
  • Uno de los principales objetivos de diseño de Typescript es que, si eliminas solo la sintaxis relacionada con tipos, el resultado sea un archivo JavaScript válido. El compilador de TS no genera código (a diferencia de PureScript, por ejemplo). La revisión estática se hace mediante un type-checker como tsc, y la información de tipos se elimina. Python también ignora las type annotations en tiempo de ejecución, y Java igualmente borra cierta información de tipos, como algunos genéricos, en el bytecode
  • Decir que “como mucho solo reduce el paso de transpilar y no mejora la seguridad” puede ser un poco engañoso. Que Node ejecute TS directamente no aumenta por sí mismo la seguridad del type-checking, pero el type-checking puede hacerse por separado en el editor o con otras herramientas. Al soportar la ejecución directa de TS, Node reduce muchísimo la barrera de entrada para usar TS y ayuda indirectamente a la seguridad de tipos
  • Typescript nunca prometió garantizar mejoras de seguridad. Es un malentendido común. TS no tenía un modo o información de runtime, y si no corrías el type-checker, podía ejecutarse incluso con errores graves de tipos. En sentido estricto, Typescript se parece más a un linter
  • Poder ejecutar scripts directamente sin build/transpile me parece extremadamente conveniente. Si necesito type-check, correr tsc me funciona perfecto
  • En mi proyecto ya uso una configuración igual con tsx, que también permite ejecutar sin build/transpile. Durante el desarrollo es muy útil. Gracias a --watch de tsx, levanto el servidor directamente desde el código fuente TS y se reinicia automáticamente cuando hay cambios. Ahora quizá se pueda armar un entorno parecido solo con nodemon y funciones integradas de Node. Para hacer type-checking en runtime haría falta soporte a nivel de v8, y eso sería casi una reescritura completa
• En realidad no ejecuta todo Typescript, sino que solo soporta un subconjunto. El título puede sentirse exagerado. Existe el riesgo de que este cambio haga que TS se use solo como linter, y que varias funciones potentes de TS que no pueden implementarse solo con type stripping terminen quedando marginadas
  • Me pregunto cuáles serían exactamente esas funciones de TS que no se pueden resolver con stripping. Aparte de enum, pregunto qué casos reales de uso hay que la gente de verdad use