Node.js adds experimental support for TypeScript

Original Article ↗ Hacker News Discussion ↗

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.”