[friendzis]

> I like to write my code and not too concern myself with types until I’m close to committing

I'm genuinely curious here. How do you ensure contract correctness? The whole point of static typing (or rather explicit typing) is to declare and enforce certain contract constraints prior to writing [client] code, which prevents certain bugs.

What's the point of using type-safe language if you deliberately circumvent type safety? If you "fix type errors" by declaring things to be strings you do not get much more type safety from TS than plain JS.

Or am I hugely missing something here?

[bichiliad]

This is a good question. I had a hard time drawing a line between perfect type contracts and dealing with JavaScript's idiosyncrasies. There is a lot of behavior in JS that is very hard to produce strong, reliable types for. If someone overwrites a prototype somewhere, your types are probably incorrect no matter what you do. Add in the fact that TS types can't really be accessed at runtime (mostly) and it makes type guarantees even harder to enforce with 100% accuracy.

It helps to think of TS types as a guarantee of behavior and an encoding of intention, and of TS itself as a really smart linter. As long as you use my function according to these types, it'll behave as expected. If it doesn't, that's my problem and I'll fix it. If I say my function returns a string, you can use my function's return types as a string with the confidence that that's how I expected it to be used. TS will make sure that everything agrees with my type assertion, which removes the need for checking the types of parameters in tests, for example.

[Vinnl]

You ensure contract correctness by encoding it in the types. However, while developing, you might still be figuring out the contract.