Is it not a problem in practice when TS type declarations and their associated JS code are written by different people at different times for different versions of a library?

I have no experience with maintaining TS projects over a longer period of time, but I have started some experimental TS projects where I was looking for type declarations.

What I found didn't seem to have any formal reference to a specific version of the library. I found that a bit scary. Not sure if it actually causes problems though.

Not caused us any yet over 3 years. You've got to think of it as the opposite, when we find a missing method because we at some point updated a library, we update the ts definition.

So it's not that it's a source of errors as most libraries are backwards compatible.

> Is it not a problem in practice when TS type declarations and their associated JS code are written by different people at different times for different versions of a library?

It can be. But most popular libraries have very good version syncing, or even include definitions in the module itself. In the worst case, or if there are no typings available at all, you can just import the plain js, and use it untyped, which can be acceptable if it is not used in a lot of places.

> didn't seem to have any formal reference to a specific version

Yeah. It mostly works if you install the latest version of them both at the same time. Sometimes I've had to fiddle with backing the definition or the module back a version to get them to match.

> The TS API in my case had something like 90% less errors

That sounds like a red flag to me. I hardly have any type related bugs in my pure JS server code. Must be a poor developer in the team. Too easy to blame JS for that.

If Typescript can deliver 90% less errors with the same team, saying "Must be a bad developer" is a useless comment.

If TypeScript let's that developer make good code, then the variable is JavaScript.

That's the great thing about Type systems. It doesn't matter if the development team is amazing or not. Typescript still makes huge classes of errors impossible. It also speeds up development due to superior IDE support.

I've only used TS on the frontend, but I had the same opinion as you until I dug into a couple of TS projects. I don't know if I've ever caused a JS production bug that was a type error at its core, but I've had plenty of bugs like that in development. TS lets me cut out those little dev cycles where I'll write some code, rebuild the app, then see an obvious error in the JS console when I run the app. That adds up to a lot of wasted time over a week of coding. Smart autocomplete and smart variable renaming is also really nice, and I have way more confidence refactoring a TS project than a JS one. I think using TS does result in fewer production bugs, but the big win for me has been having fewer development bugs.

Types are good for more than just "int instead of string". What you consider a type related error is likely not the full set of errors a type system can prevent.

Aside from the other responses you are getting, consider that the "90% less errors" doesn't actually tell you anything about the overall quality of either codebase. It could be a million lines of JS/TS with 10 errors found in the JS vs 1 in the TS. That would be a 90% reduction, but 10 errors in a large codebase would still be pretty excellent.

A great carpenter can hammer a nail with a screwdriver, but that doesn't mean it's a good idea.

When the tools help you, a good developer can focus on making better things rather than not making mistakes.

Tests are also a red flag for the same reason. Just suck less, I always say!