Una experiencia con Node, TypeScript, TS-Node y ESM que funciona

Artículo original ↗ Discusión en Hacker News ↗

Los desarrolladores de Node.js describen una fricción significativa al combinar TypeScript, `ts-node` y módulos ECMAScript, especialmente cuando los proyectos incluyen monorepos, frameworks de pruebas como Jest y árboles de dependencias complejos. Muchos sostienen que las configuraciones repetitivas que “simplemente funcionan” ocultan una complejidad importante, y en su lugar abogan por herramientas más sencillas como `tsx`, Vitest o incluso runtimes alternativos como Deno y Bun, que buscan hacer más fluido el soporte de TypeScript y ESM. Otros se oponen, diciendo que la pila puede hacerse fiable con la configuración adecuada, pero reconocen que la mala interoperabilidad, los estándares cambiantes y la escasa documentación sobre la resolución de módulos han hecho que el ecosistema actual sea inusualmente frágil.

Sentimiento general sobre Node + TypeScript + ESM

  • Muchos comentaristas dicen que la combinación de Node + TypeScript + ts-node + ESM es confusa, frágil y está llena de casos límite.
  • Otros informan que para ellos “simplemente funciona” con una configuración mínima, y no entienden la dificultad.
  • Varios subrayan que el dolor suele aparecer una vez que añades varios paquetes, imports de subruta, ejecutores de tests o monorepos, no en proyectos de juguete.

ts-node frente a tsx y otros ejecutores de TS

  • Hay un fuerte apoyo para tsx como reemplazo directo de ts-node: más rápido, mejor manejo de ESM, valores predeterminados más simples.
  • Algunos antes tuvieron problemas con tsx (por ejemplo, Playwright, cobertura), pero informan que las recientes versiones v4 corrigen muchos de ellos.
  • Alternativas mencionadas: esno (ahora esencialmente un alias de tsx), tsm, node-dev, esyes.
  • Algunos evitan por completo los transpiladores en tiempo de ejecución y prefieren tsc --build --watch junto con ejecutar el JS compilado.

Pruebas, herramientas y monorepos

  • Jest + TypeScript + ESM se cita repetidamente como algo doloroso; Vitest se recomienda con frecuencia como una alternativa más fluida.
  • El ejecutor de pruebas integrado de Node se ve como prometedor, pero la integración con cargadores de TS y herramientas sigue siendo irregular.
  • Los monorepos con TypeScript, ESLint, Jest y mezcla de ESM/CJS se describen como “vudú” y frágiles; unos pocos comparten plantillas que les funcionan.

Configuración frente a comprensión

  • Debate entre “simplemente copia estos archivos de configuración” versus aprender qué hace cada opción.
  • Algunos sostienen que los ejemplos que funcionan son el mejor punto de partida; otros dicen que eso fomenta configuraciones de “culto al cargador” que se rompen al actualizar.
  • Quejas de que el ecosistema de TS/Node carece de buenos documentos de “explicación” sobre cómo interactúan la resolución de módulos y las opciones de tsconfig, especialmente con ESM.

Diseño de ESM y fricción del ecosistema

  • Muchos culpan a la implementación de ESM de Node por las fracturas del ecosistema (incompatibilidad CJS/ESM, type: module, pérdida de __dirname, problemas con exports de subruta).
  • Otros argumentan que TypeScript y herramientas como Jest tardaron en dar soporte a ESM a pesar de años de advertencias.
  • Algunos critican con dureza el propio diseño de ESM, afirmando que CommonJS era más simple y “suficientemente bueno”; otros responden que ESM declarativo permite mejor optimización y módulos nativos del navegador.

Alternativas: Deno y Bun

  • Deno es elogiado por TypeScript que “simplemente funciona”, herramientas integradas y seguridad, pero la compatibilidad con el ecosistema (especialmente con npm) y algunas peculiaridades siguen presentes.
  • Bun se ve como algo que mágicamente suaviza los problemas de ESM/CJS y ofrece una gran DX, pero también como algo muy nuevo y aún con errores; muchos dudan en usarlo en producción todavía.