The thing I've come to realize when using languages with more robust type systems is this:
All errors in code are type errors, but not all type systems are expressive enough to fully express the invariants that logically apply to a piece of code.
That said, in nearly 40 years of programming, I've frequently encountered type errors in both my and other people's code that a type system like TypeScript’s is sufficient to statically avoid.
iirc Webpack uses it extensively in its codebase
Just having the ability to tag a functions param type as `string` is otherwise useless, other than trivial callsite validation, for instance.
That just means you've never used a powerful enough type system. With a powerful type system, it's incredibly easy to make type errors. You'll find that you spend a ton of time fixing all of these type errors that suddenly appeared in your code.
In my 15 years of engineering, exceedingly rare is the case where the underlying cause is due to using wrong types. I could count the number of times types has been problem on one hand. Instead, almost all issues are due to logic errors and missing or poorly understood business requirements.
For me, the time spent resolving TypeScript specific issues (missing type definitions, lack of support in third party libraries, general finickiness etc.) does not make it a worthwhile investment. I also did Scala for several years professionally, and while it instils rigor, I feel much the same that the price you pay isn't remotely worth the benefit you get. Conversely, I think one of the best investments you can possible make into tooling is to reduce the edit-compile-view cycle time, and you should aim for seconds at the most if not instantaneous updates. That speed of iteration will pay dividends.