> I also feel unit-level tests are less necessary with TypeScript.

Especially with strict compiler settings, including strict null checks, and the good type conventions they encourage. To give a small example, if you have a value that can either contain an error or a successful result, you can model it as the union of a success and error state. This prevents you from accessing the value until you check the result is successful (and the compiler will nicely infer the type in subsequent usages once you do.)

For me, with rigorous compiler settings and a good proficiency in type modeling, I've reached the point where I rarely have any runtime errors at all once the code compiles. Sure it might take 2% more time to write code and think through my data model, but I spend 95% less time debugging it and the end result is much more maintainable. Even using typed languages like C# and Go now leaves me slightly dissatisfied!

Honestly, good integration of union's (Algebraic Data Types) is a good chunk of what makes Rust such a comfy programming language for personal projects. Being able to use a common, standard method to say "there may be a result or there may not, and if there is, here it is" is so expressive. Since the Option type is built into the language, it comes with lots of utility methods to make things even easier on me.

With C#, I am pretty sure you can get some of what you mentioned by using stricter compiler settings.

This doesn't come as a surprise to me, since Anders Heijlsberg, wo created TypeScript, was the technical lead of the team that developed C#.

I'm using TS for front/back end but you do need runtime checking as well at a few places, even though the compiler tells you it's redundant.

Relying strictly on typing is dangerous as you might've given wrong type from data coming back from database queries and you can't tell until it has run.

The major advantage of static types is replacing tests with proofs. Tests always have (limited) coverage, but type proofs are invariant. That said, it's very possible to misunderstand what a test or a type actually means.