Node.js adds experimental support for TypeScript

Original Article ↗ Hacker News Discussion ↗

Node.js is adding experimental support for running TypeScript files directly, stripping types at load time and relying on external tools for type-checking. Commenters welcome the move as long-overdue parity with Deno and Bun and a potential simplification of TypeScript workflows, but note current limitations (no enums/namespaces, no import rewriting) and caution that production code will still likely need a build step for now. The change also rekindles broader debates about standardizing type annotations in JavaScript, performance implications, and whether TypeScript’s complex, unsound type system is the right long‑term foundation.

Scope of the new TypeScript support

  • Node can now run .ts directly by stripping types at load time; no type-checking is done.
  • Implementation uses an SWC-based transpiler that erases types and preserves locations (by replacing types with whitespace), so stack traces still match source.
  • Only “TS-for-types” is supported: features needing transforms (enums, namespaces, some decorators, etc.) are currently unsupported.
  • It does not rewrite imports, convert ESM↔CJS, or touch runtime semantics.

How it’s intended to be used

  • Many commenters see this as great for:
    • One-off scripts and REPL-like usage.
    • Development and testing without extra tooling.
  • Multiple people stress that for production you still likely want a build step:
    • Better control over JS targets and polyfills.
    • Full TS feature support and sourcemaps.
  • .ts in node_modules is explicitly not supported to avoid ecosystem breakage.

DX, ecosystem, and competition (Bun/Deno/etc.)

  • Seen as Node catching up with Deno and Bun’s “batteries-included” DX (TS, test runner, tooling).
  • Some argue competition from Deno/Bun is clearly pushing Node toward nicer defaults (built-in test runner, sqlite, TS).
  • Others note Bun/Deno still struggle with stability, compat, or platform support, so Node staying conservative is appreciated.

Typing philosophy and TS complexity

  • Strong enthusiasm for static types; several claim most devs they work with prefer them.
  • Others like dynamic JS for quick scripts and small PoCs; they use any/unknown or skip typing early on.
  • Long subthreads debate:
    • TS’s unsound type system vs. “sound” academic systems.
    • Whether unsoundness is a real problem in practice (most say “rarely”).
    • TS’s advanced types (unions, intersections, mapped/conditional types) as both powerful and a source of “type soup” and unmaintainable meta-programming.

Standardization, browsers, and future directions

  • Discussion of TC39’s “type annotations” proposal: standardizing erasable syntax, not TypeScript semantics.
  • Some want full TS standardized into JavaScript; others see that as a serious mistake that would freeze TS and burden browsers.
  • Several suggest a future where:
    • The TS compiler is used only as a type-checker.
    • Runtimes (Node, browsers) just ignore types but can share a common syntax.

Concerns and open questions

  • Worry about TS syntax evolving faster than Node LTS; Node plans to version the internal transpiler separately to mitigate.
  • Some fear this will push more libraries to ship raw .ts, complicating non-Node or older-tooling users.
  • Performance impact vs plain JS is not yet clear in the thread; startup costs and large-app behavior are flagged as “to be seen.”