I know it’s not perfect, but I’m pretty content writing schemas and types as validators with zod and deriving my types from those. That you can derive the types easily and the validation then evolves with your typing is really nice.

I’ve worked with people who find it too complicated or they feel like it should be baked into the language, but I’d argue there are so many contentious design choices in these libraries that it might actually be best to be an implementation choice, selected based on a project and its specific needs.

Zod has been very good to me though. It’s quite easy to get up and running with, and its API has never gotten in my way when scaling things out.

My one complaint is that certain patterns I love, such as runtime validation with zod and deriving types from schemas, doesn’t necessarily always play well with something like pattern matching in ts-pattern. The type definitions behind these libraries are labyrinths, and cases where something seems like it should work won’t always behave as expected. On some level, I do wish these were seamless language level features, though I fully recognize these are selfish desires.

But imagine having runtime safety combined with exhaustive pattern matching. I’d be very happy to have that.

I have huge doubts whether I'd like JS to have it really.

I feel like Promises, decorators and the new pipe operator all went into the wrong directions with their implementations.

How do you feel like promises went in the wrong direction?

(I'd also add modules to your list fwiw, they were designed without taking performance into account.)