That's only partially true for Typescript and requires a lot of discipline.
TS is continuously getting better, but it's still possible to lose type safety with some constructs without the compiler warning you about it at all.
The third party typings for JS dependencies are also often not a 100% correct, especially for rare code paths and edge cases.
And due to how easy it is to fall back to any, there are also Typescript native libraries that don't uphold the guarantees they seem to give.
Typescript is great, but it's far from bullet proof, and it's extremely frustrating to deal with bugs that the type system supposedly should have prevented.
We're lucky where no- or very shallow- dependencies for our backend services are possible.
I hear from collegues it's different world on f/e.
It's true there are tons of poor quality libraries - both in pure js and ts. We try to avoid this transitive dependency explosion nonsense alltogether.
Even well known libraries like lodash, which are not typescript first – are simply too dynamic. If ts doesn't offer precise types on functions – we avoid those.
From our experience it looks like it pays off well to put an extra effort to guarantee that static types are correct and precise – no dependencies or trimmed to absolute minimum, rely on ts first code (usually ours), no dynamic fiddling that can't be expressed in ts, no any, no pretending via casting/non-null assertions, parsing/runtime-assertions on io-boundaries etc. Together with other techniques like branded types typescript can enter critial systems in enterprices – areas where js would never be allowed to exist. As you say it requires discipline – but I wouldn't call it "a lot", not in our case at least, the effort/benefit ratio is no-brainer in our case and at the end – it's honestly very pleasant language to work with.
Some of those issues can be remedied by linting rules (preventing unsafe use of any), but typing of dependencies can be a headache. Even 1st party typing and Typescript dependencies can regularly be wrong if type safety was not important to whoever wrote them.
Comments
That's only partially true for Typescript and requires a lot of discipline.
TS is continuously getting better, but it's still possible to lose type safety with some constructs without the compiler warning you about it at all.
The third party typings for JS dependencies are also often not a 100% correct, especially for rare code paths and edge cases.
And due to how easy it is to fall back to any, there are also Typescript native libraries that don't uphold the guarantees they seem to give.
Typescript is great, but it's far from bullet proof, and it's extremely frustrating to deal with bugs that the type system supposedly should have prevented.
We're lucky where no- or very shallow- dependencies for our backend services are possible.
I hear from collegues it's different world on f/e.
It's true there are tons of poor quality libraries - both in pure js and ts. We try to avoid this transitive dependency explosion nonsense alltogether.
Even well known libraries like lodash, which are not typescript first – are simply too dynamic. If ts doesn't offer precise types on functions – we avoid those.
From our experience it looks like it pays off well to put an extra effort to guarantee that static types are correct and precise – no dependencies or trimmed to absolute minimum, rely on ts first code (usually ours), no dynamic fiddling that can't be expressed in ts, no any, no pretending via casting/non-null assertions, parsing/runtime-assertions on io-boundaries etc. Together with other techniques like branded types typescript can enter critial systems in enterprices – areas where js would never be allowed to exist. As you say it requires discipline – but I wouldn't call it "a lot", not in our case at least, the effort/benefit ratio is no-brainer in our case and at the end – it's honestly very pleasant language to work with.
Some of those issues can be remedied by linting rules (preventing unsafe use of any), but typing of dependencies can be a headache. Even 1st party typing and Typescript dependencies can regularly be wrong if type safety was not important to whoever wrote them.
Absolutely, some of linter rules are very useful, ie. type-aware ones.