Zod is really useful when you have complex data coming in and you're not sure what the structure may be at runtime. Zod helps you prove really quickly that the data coming in is of the appropriate shape.
Now, it's already possible to take certain kinds of objects and narrow their types using plain TypeScript and have all kinds of really solid guarantees about how you're checking the data (and the checks are always going to be as fast as the types will allow, which is great). But Zod is important for being able to take unstructured data and ensure it's compatible with your desired types, in a flexible way, at a cost to runtime speed.
I don't think the Zod stuff is going to find its way into the TypeScript language / standard library. There's very little actual codegen being done in TypeScript (sugar around enums notwithstanding), most of the work to convert it to JS is just checking the types and then stripping them. What you might see instead are improvements to type narrowing.
Zod is great. It has some weaknesses - you can't just reuse types from external libraries; it can be verbose.
There are some libraries that provide a cleaner experience (e.g. typescript-is/typia). But they rely either on code generation or extending the TypeScript compiler while Zod just makes do with some clever typing.
TypeScript itself will never integrate something like this as it goes against their design goals[1].
zod and yup both give runtime types and they're great. They can also export typescript types. But as far as I understand it, typescript is a layer "on top of" javascript that does not exist at runtime. It all gets stripped and you're left with valid javascript. So no – I doubt it. They exist in different worlds.
zod or yup gets you quite a bit of the way there in practice - when you would reach for a Typescript type, making it in zod instead is more verbose but gives that runtime layer.
It patches the typescript compiler (which pointedly considers runtime type information out of scope) with its own type compiler that emits a bespoke bytecode that is executed in a bespoke VM to communicate runtime type information to both server and client as needed. https://docs.deepkit.io/english/runtime-types.html
It's very much in the alpha stage, but it's really well thought out - there's a tremendous degree of care the developer is taking towards code cleanliness and developer experience. I'm torn between wishing this project to have a fully funded team and take the world by storm, vs. "letting them cook" so to speak and seeing the developer experience unfold organically. Either way, it's a breath of fresh air into the Typescript ecosystem!
I've found libraries like Zod useful when interacting with external data sources like a database. Slonik[1] uses Zod to define the types expected from a SQL query and then performs runtime validation on the data to ensure that the query is yielding the expected type.
I don't think it's necessary to use Zod/runtime validation everywhere, but it's a nice tool to have on hand.
TypeScript management feels very strongly about remaining fully compilable to JavaScript, with no runtime component. So likely not as a native feature, no.
I have been reading about Zod which gives runtime type validation.
Is this a good fit to TypeScript and are we likely to see such functionality added to TypeScript?