A Node, TypeScript, TS-Node and ESM experience that works

Original Article ↗ Hacker News Discussion ↗

Node.js developers describe significant friction when combining TypeScript, `ts-node`, and ECMAScript modules, especially once projects involve monorepos, testing frameworks like Jest, and complex dependency trees. Many argue that boilerplate configs which “just work” hide important complexity, and instead advocate for simpler tooling such as `tsx`, Vitest, or even alternative runtimes like Deno and Bun that aim to make TypeScript and ESM support more seamless. Others push back, saying the stack can be made reliable with the right configuration, but acknowledge that poor interoperability, shifting standards, and weak documentation around module resolution have made the current ecosystem unusually brittle.

Overall sentiment on Node + TypeScript + ESM

  • Many commenters say the Node + TypeScript + ts-node + ESM combo is confusing, brittle, and full of edge cases.
  • Others report it “just works” for them with minimal config, and don’t understand the struggle.
  • Several stress that the pain often appears once you add multiple packages, subpath imports, test runners, or monorepos, not in toy projects.

ts-node vs tsx and other TS runners

  • Strong support for tsx as a drop‑in replacement for ts-node: faster, better ESM handling, simpler defaults.
  • Some previously had issues with tsx (e.g., Playwright, coverage) but report that recent v4 releases fix many of these.
  • Alternatives mentioned: esno (now essentially an alias of tsx), tsm, node-dev, esyes.
  • Some avoid runtime transpilers entirely, preferring tsc --build --watch plus running the compiled JS.

Testing, tooling, and monorepos

  • Jest + TypeScript + ESM is repeatedly cited as painful; Vitest is frequently recommended as a smoother alternative.
  • Node’s built‑in test runner is seen as promising, but integration with TS loaders and tools is still spotty.
  • Monorepos with TypeScript, ESLint, Jest, and mixed ESM/CJS are described as “voodoo” and fragile; a few share templates that work for them.

Configuration vs understanding

  • Debate over “just copy these config files” vs learning what each option does.
  • Some argue working examples are the best starting point; others say this breeds “cargo cult” configs that break on upgrades.
  • Complaints that TS/Node ecosystem lacks good “explanation” docs about how module resolution and tsconfig options interact, especially with ESM.

ESM design and ecosystem friction

  • Many blame Node’s ESM implementation for ecosystem fractures (CJS/ESM incompat, type: module, loss of __dirname, subpath exports issues).
  • Others argue TypeScript and tools like Jest were slow to support ESM despite years of warning.
  • Some strongly criticize ESM design itself, claiming CommonJS was simpler and “good enough”; others counter that declarative ESM enables better optimization and browser-native modules.

Alternatives: Deno and Bun

  • Deno is praised for “just works” TypeScript, built‑in tooling, and security, but ecosystem compatibility (especially with npm) and some quirks remain.
  • Bun is seen as magically smoothing over ESM/CJS issues and offering great DX, but also as very new and still buggy; many are wary of using it in production yet.