TS is very pragmatic in the way it allows you to convince it you know what you're doing and, really, this will be fine in reality even if the types don't really agree. It's a DX tradeoff I believe is usually worth making.
But it is comical on a certain level how you'll choose to use a tool to point out the potential of problems with your code but then sometimes ignore it / tell it it is wrong when it does :-)
Usually when the tool fails to be expressive enough for me to comfortably communicate that no, it’s definitely going to be T, not `string`
Using Object.entries/keys/fromEntries and Array.reduce are my least-favourite moments with TS because of how darn wordy and assertive I have to get.
I disagree here. Typescript allows you to lie about your code, and that's only a ticking time bomb that will work until it doesn't. The workaround might work in the current state of your application, but over time if things/people change, it makes it much more difficult to reason about things.
Because typescript allows interfaces to have additional properties, five levels up the call stack someone will pass in an object that has extra properties for whatever reason, and then the assumptions we once made about the code fall out and you ship an unknown bug.
I've worked on many dynamically types systems and have no problems thinking in terms of compile time, run time, and macro expansion if you're so lucky, but some people just want the computer to say yes.
Oh and miss specification of the system will happen in all. Even when computer says yes.
I could just as easily argue with equivalent experience the exact opposite.
If you’re acting like a type system suddenly means that you aren’t making trade-offs, that’s a huge sign of incompetence in my eyes. And if you AREN’T acting like this, what precisely is the issue here?
Not everything needs to be an argument. The parent commenter is quite rightfully pointing out some nuance, not necessarily arguing that Your Preferred Way To Do Things is wrong.
Those words do not appear in the comment that I replied to.
The argument that I'm challenging is this opening line:
> It's amazing how in practice it's not really a big deal.
I'm not discarding their experience, but from my own experience I would argue the opposite — in practice it really is a big deal.
What I don't understand is why you would chose to use Typescript, and then opt out of the only/main benefit it actually has. At that point you're just writing dynamically typed Javascript with more keyboard presses.
Of course, you'd run into the same issue in regular Javascript by expecting a base class and receiving a child class of that base.
That's a terrifyingly vague comment!