Yeah agreed - saying "node can execute typescript files" is a bit misleading. More accurate would be "node can find-and-replace type information with spaces from .ts files and try and executing them as if they were plain JavaScript"

I suspect this would only handle the most rudimentary and basic typescript files. Once you start using the type system more extensively I suspect this will blow-up in your face.

It's kinda a shame. What a missed opportunity to do it properly (rather than relying on third party plugins etc)

Edit: if you are just using typescript for type checking at build time (i.e. the most basic rudimentary typescript files) the sure fine this may help you. But typescript also generates JavaScript code for missing features e.g. proper class access modifiers, generics, interfaces, type aliases, enums, decorators etc etc. typescript generates JS code to handle all that, so you're going to have a bad time if node just replaces it with the space character at run time.

▲

bitterblotter 5 days ago | parent | next [-]

Just to give context here, NodeJS doesnt support enums, namespaces and class parameter properties. All of these have been described as regrets by Anders Hejsberg, and none of them prevent advanced use of the type system at all.

Source: 49m 43s https://m.youtube.com/watch?v=NrEW7F2WCNA

	▲	marcjschmidt 4 days ago \| parent [-]
		Yes, they regret them because they hinder adoptions. Why? Because nobody chose to add TSC with all features in their runtime because TSC is extremely slow. They know they can skyrocket adoption by limiting the language. That's the reason they regret it. This is just a strategy to increase adoption. Not because they are bad features. They are in fact very useful, and you should not stop using them just because your favorite runtime decided to go the easy way and only supporting a subset of TS by stripping types. You should rather switch the runtime instead of compromising your codebase.

▲

koito17 5 days ago | parent | prev | next [-]

TypeScript 5.8 added a configuration option[1], where the compiler emits errors when using language features that result in code generation (e.g. enums). It's expected that people wanting to run TypeScript through "erase-only" transpilers will use this option.

Of course, everyone else is free to use enums, decorators, class parameters, etc., but for quick prototyping or writing simple scripts in TypeScript, Bun has been good enough for me, and I assume Node will be "good enough" as well.

[1] https://www.typescriptlang.org/docs/handbook/release-notes/t...

▲

sdfhbdf 5 days ago | parent | prev | next [-]

> node can find-and-replace type information with spaces from .ts files and try and executing them as if they were plain JavaScript

That’s what all the other tools like ts-node and tsx do already.

I’m not sure what more are you expecting to do?

Typescript is build time type checked, there is no runtime component to TypeScript. If you want type checking you run tsc.

I think this is a great step in the right direction by node. It will save transpiration on the server and improve stack traves and whatnot.

> Once you start using the type system more extensively I suspect this will blow-up in your face.

I don’t see why. There isn’t any more runtime information in “complex” TypeSceipt types than in simple ones. It’s all build time - see above.

> What a missed opportunity to do it properly

Please explain in more detail what “doing it properly” means to you. Including the typechecker? If so that wouldn’t make sense - they would be competing with TypeScript itself, they shouldn’t, all the “third party plugins” rely on tsc for type checking.

	▲	dingi 5 days ago \| parent \| next [-]
		> Typescript is build time type checked, there is no runtime component to TypeScript. Not exactly. Typescript enums and decorators are examples.
	▲	marcjschmidt 4 days ago \| parent \| prev [-]
		> I think this is a great step in the right direction by node I think it's the opposite. It will be a net negative, since people will now run TS by default without type checking. Wasting so much time chasing weird runtime errors - just to end up running the full blown TSC type checking again. They will also write very different TS now, trying to workaround the limitation and arguably very useful features like Enums, constructor properties, etc. This has real negative effects on your codebase if you rely on these, just because Node chose to support only a subset. It's interesting to see the strategy now and to see people even gaslighting people into believing no type checks and less features is a good thing. All just because of one root cause - TSC being extremely slow.

▲

9dev 5 days ago | parent | prev [-]

I have been using this feature to remove the transpilation step during development for a rather large monorepo that makes extensive use of very complex types and haven’t noticed any errors whatsoever at runtime.

You’re downplaying this quite a bit. Node being able to execute TS files slashes a lot of tooling in half, especially during development when you want to modify files and retry in quick succession.

Besides, I’m not so sure this cannot be expanded in the future to adopt validation features before stripping the type information. For now it solves some major pain points for a lot of people.