Migrating 300k LOC from Flow to TypeScript

A sound type system shouldn't allow you to write such a parser function without either you lying in its implementation or having to use unsafe code.

In a year or two, once everyone has switched to use `unknown` instead of `any` in functions which at runtime return… uhm… unknown values, we'll all be much safer. Because we'll be forced to use proper parsers and validators.

Stop being dismissive. You know that’s not the point.

I have a few applications that use the same API, and it’s consumed using a shared library in Typescript. There’s a little bit of code that takes raw messages, parses and validates them, then returns typed objects. This means we can use those typed objects confidently throughout the rest of the codebase, making some useful guarantees about the content of them and detecting errors at compile time. Parsing code is isolated and tested in a small area, like you light use unsafe code in Rust.

Yes, it would be nice if this was easier, such that parsing was automatically handled based on those types (and I don’t doubt that there are projects out there that do this). But that obviously doesn’t mean that no value is added.

It’s totally fine if Typescript doesn’t suit your applications, or your way of working - but it might be useful to consider that other people aren’t idiots.

Well, as a someone who had the same initial feelings with TypeScript when it came "oh it slows me down, these types are just a waste of time", I get where you're coming from but think that you have some other issues than TypeScript with your team and project. First of I'd want to say that most of your complaints about "no runtime type validation" in the context of TypeScript/JavaScript is just how unreliable JS is as a language. You just can never be sure and even with TS you can get all the boilerplate of TS with zero benefits if you resort to using `any` anytime you feel too lazy to add difficult types.

Which leads to my next point, the slowness of writing TS compared to JS. I don't know how you maintain your code bases but from my experience any time a new programmer comes in who doesn't know anything about the code, they'll be from time to time wondering, in their heads or aloud, what the hell is the type of some parameter or why something fails on some weird undefined value bug. There's just so much trial and error with JS whereas with TS I don't have to look up at the broken website to see all the errors hitting me as it's all caught with the compiler. Pretty basic static typing stuff but it all comes down to more time writing code, sure, but less time over time maintaining it. And overall the readability of your code is just night and a day with special emphasis towards young programmers or those unfamiliar with the codebase.

What I think has happened is, that you've been bitten by some weird problem regarding API endpoints and incorrectly assumed your typings would hold with an external data source. That just sounds poor programming (don't you use validation libraries such as Joi?) and frankly, a problem entirely of JS itself that such anomalies would happen. If my API starts returning arrays instead of objects sure as hell I'd be angry too but that's just not how it should work. Not a problem of TypeScript, at all.

About the other problems - haven't faced those myself. Most problems I've had have been with writing the correct types especially when they get complex with generics. Sometimes TSC has been annoying and also exporting types into a single typing file seemed quite laborious last time I tried.

Your view is correct but irresponsible in practice. Validating the schema of all parameters of every method call (because you can never trust the caller in dynamic languages) would be prohibitively expensive. A compiler which injected these checks into every method preamble would have incredible correctness, but would create functionally useless code (if performance is a feature).

> C++

What happens when you call main(argc, argv) with the incorrect argc parameter? There the exact same problem that TypeScript faces at the start of every single C/++ program.

Validate your payloads with JSON schema if you don't trust the server/backend. JSON schema is designed to type-check at runtime and is therefore the correct tool for the job.

Don't curse the hammer if it is unable to loosen bolts.

I don't get this argument at all.

If you look at a typical call stack - in any language - going from the frontend all the way to the database, there will be hundreds of lines. Two, maybe three of those will be remote jumps.

Every one of those calls is an opportunity for a contract mismatch. Even if static type checking misses a half-percent of your calls, it's still working to enforce 99.5% of your contracts. The value of that is hard to oversell.