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

> Typescript is build time type checked, there is no runtime component to TypeScript.

Not exactly. Typescript enums and decorators are examples.

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