i don’t think you’ll see this at the typescript level, and you won’t see anything like this that compiles to javascript. specifically, compiling typescript to javascript with runtime checks would not actually be very useful.

typescript is pretty ambiguous about a lot of the things that would need explicit definition for runtime safety, and anyways we already have tools for that - it’s called zod.

and comprehensive checks would incur a significant runtime penalty, unless they were restricted to external interfaces, which is what you’re really concerned about. we already have tools for that - protobuf, swagger, etc.

anything else is sharing a runtime with you. so either it’s in your ide, and you just don’t write shitty code; or you’re trapped in some kind of demonic javascript prisoner’s dilemma, and you are mutable.

so typescript is basically ‘good enough’ for developers.

thinking forward anyway, and assuming you’re really willing to share a runtime with a stranger…

node doesn’t really operate in that kind of context, but maybe browser code does. i could imagine a framework based on web components, workers, and maybe iframes, taking advantage of message boundaries to enhance analysis and conceal code generation. it’s not that much better than typescript.

but if you want efficient runtime checks, and you want to leverage static analysis and strong module boundaries to scope the type-checking codegen, and you probably need additional syntax, you might as well target wasm.

Yeah, but Zod and all of the runtime schema libraries all kind of add verbosity to the type system compared to say something like Typia[0] which AOT compiles the type checks (and ends up being way more elegant).

Caveat is that there are some restrictions with the compiler and some possible footguns (duplicated declarations bloating code).

[0] https://typia.io/

> you won’t see anything like this that compiles to javascript

https://github.com/microsoft/TypeScript/issues/47658