Writing a Typescript program that takes external input but has no runtime error checking is already a mistake, though. Dealing with external input requires type assertions (since Typescript doesn't know what the program is getting at compile-time) and if you write type assertions without ensuring that the assertions are accurate, then that's on you, not Typescript.

However, if your point is that Typescript can lull people into a false sense of safety, then sure, I take your point. You have to understand where type assertions are coming into play, and if that's obscured then the type safety can be illusory. The benefits of Typescript require you to make sure that the runtime inputs to your program are sufficiently validated.

> Writing a Typescript program that takes external input but has no runtime error checking is already a mistake, though.

If it's a service, yes, and that's true no matter what technology the service is using. If it's a library, no, because...

> and if you write type assertions without ensuring that the assertions are accurate, then that's on you, not Typescript.

That's on whoever is using the library, not the library author. If the library author provides type definitions, and you as the consumer choose to ignore them, then it's on you.

TS certainly thinks of external input as a boundary requiring safety, but usually that would mean form input or CLI args parsing or something.

Usually there's little if any protection against a JS caller providing wrong-type args to TS functions.