[jauco]

Newer versions of node can run typescript directly[1]. The one where types are simply stripped is considered stable[2] (but you can’t use syntax that node doesn’t understand, such as enums).

They’re working on making features work that require some transpilation as well

[1]: https://nodejs.org/en/learn/typescript/run-natively [2]: https://github.com/nodejs/node/pull/58643

[eyelidlessness]

Completely picking nits: Node doesn’t understand types at all, the distinction is between what TypeScript now calls “erasable syntax”[1] versus syntax excluded by that. The exclusion of enum isn’t likely to affect many projects (because enum has long been panned by most users). Same with namespace. By far the most likely incompatibility is “parameter properties”, ie class fields assigned in the constructor signature.

1: https://www.typescriptlang.org/tsconfig/#erasableSyntaxOnly

[veidr]

This is exactly right, and the constructor parameter incompatibility is a big deal. The other two aren't nothing, either, even if enums are generally not the prevailing best practice in most cases.

This is an interesting development, but it's not really "running TypeScript code" its "almost running TypeScript code".

With alternative runtimes like Deno and Bun able to run real TypeScript code (and type check it, lint it, test it, etc) using a slightly watered-down, not-fully-compatible dialect of TypeScript, just so that it can run on Node without a build step, really isn't a very compelling argument.

It'd be different if TypeScript announced "TypeScript will remove these features to work around Node's limitation — compatibility is more important", but they haven't.

(And I wouldn't personally love it if they did. Deno and Bun are ahead of Node on several different axes, and other runtimes are coming, too — if Node can catch up, then great, but if it can't, then it should rightly be left behind.)

There's still no real alternative to Node for many large frontend apps in production, but for a lot of other TypeScript use cases — build tooling, backend APIs, CLI apps, edge functions — modern TypeScript in the Deno/Bun style (ESM, full filename imports, run/typecheck/lint/test with no user-configured build step) has significant benefits.

Both Deno and Bun have extensive — and necessary — backward compatibility shims to enable interoperability with what I've started calling "legacy Node JS/TS". You can use the Node APIs (but should explicitly import those things with "node:" in your import specifier. You can use NPM packages (even CommonJS ones, although Deno prohibits CommonJS in new code, a stricter line than Bun draws).

I don't think using Deno and Bun is a huge bet on those specific (VC-backed) runtimes, either, because there is a shared vision of what "modern TypeScript" looks like, it works with both of those tools, and I think there will be multiple runtimes that support that vision for as long as TypeScript is relevant, even if both Deno and Bun were to go sideways.

Whether Node itself will become one of those modern runtimes is an interesting question. This is a step in that direction, it looks like, but it's still an open question.

[nsonha]

> enum has long been panned by most users). Same with namespace

Why? Would you would rather do a smurf naming convention than having your consts, DTOs, events, errors and what not neatly organized under the name of the function that uses it?

[alpinisme]

Some people hate enums but they’re the only easy form of nominal typing in typescript, and for that alone you can pry them from my cold dead hands.

[ethan_smith]

The --experimental-strip-types flag is actually stable in Node.js 22 (released May 2024), so you can run TypeScript directly with `node --strip-types file.ts` without the experimental prefix. This makes Node's native TypeScript support even more practical for everyday use.

[linkage]

Node.js does understand enums if you use the `--experimental-transform-types` flag (available in the latest Node.js LTS release). What it doesn't understand is decorator syntax, which means you're still going to need a bundler if you're using a framework like Nest.js or Inversify.

[theThree]

It still have issues. Example: `import foo from "./Foo"` doesn't work. You have to `import foo from "./Foo.ts"`

[veidr]

That's a feature, not a bug.

When you think about it (even drunk as hell while mid-fall bungee jumping) the latter form is sensible and the first is nuts.