I think this misses the biggest problem with Typescript, which is testing. I recently added some functionality to an open source project in Typescript, and it took me at least 3x as long as it would have had it not been in TypeScript. When you’re mocking an object and it’s of a type that declares dependency on 10 types, half of which are implementations which themselves have declared dependencies on implementations, the only realistic choice is to use the real object that’s NOT under test (which you shouldn’t do). And then there’s how do you build THAT, when some of the dependencies you still need to supply are generics, etc. You wind up having to do a deep dive into code that’s completely unrelated to what you’re doing just to understand that web of dependencies.

And it totally doesn’t prevent people from doing things that are really, actually bad practice, like undeclared dependencies on Singleton objects or violating the practices of the framework they’re using (this was ReactJS, they had objects everywhere that not only mutated THEMSELVES, but then generated side effects freaking everywhere).

And that’s the issue. Giving developers something new to learn that’s complicated (and becomes more complicated the worse your practices are) doesn’t prevent them from doing stupid things that really f you up. It just distracts them from where their focus should be — learning what good software really looks like. But honestly if you don’t have anyone on your team that knows that and can help everyone else get there, maybe the best you can do is try to slap a Typescript bandage over the top of the crap you have.