3 ms·
I love zod and use it daily. It is also the most frequent thing where junior developers get stuck. TS tooling doesn't make it very easy to work with large extr
by lf-non 3y ago
I love zod and use it daily.
It is also the most frequent thing where junior developers get stuck. TS tooling doesn't make it very easy to work with large extracted types though it is head and shoulders above other mainstream languages. The error messages often become incomprehensible walls of text once your types are Complex enough, and then tsserver will just truncate the type info in pop overs making them useless.
I am personally OK to live with all of the above. My single issue with zod is that it is not easy to use if you don't own your types. If your types are coming from a third party lib you don't have an easy path to derive runtypes from them. If the concept of runtypes was supported by the compiler itself, this could have been possible but as a userland library zod can't handle this easily.
- kristiandupont 3y agoWhy would a ts-native offering produce better error messages when it comes to complex types? That is an issue with TS in general (or rather, with complex types in any typesafe language).
- lf-non 3y agoNo. Imagine a Zod schema like: const UserLocation = z.object({ address: Address, coords: Coords }) where Address, Coords are other zod schemas. Now if I infer a type like: type IUserLocation = z.infer<typeof UserLocation> Th inferred IUserLocation is something like: type IUserLocation = { address: { city: string, country: string, ... }, coords: { lat: string, long: string } } The extracted type does not refer to separate Address, Coords type, it is a single complex type that represents the complete nested structure. So if I do something like: const userLocation: IUserLocation = { address: { ... }, coords: { lat: 0, long: 0 }} The error message is complex because it (effectively) says that coords.lat was expected to be a string from IUserLocation["coords"]["lat"] but it was number However, if I define a ts interface directly: interface IUserLocation { address: IAddress coords: ICoords } now any errors reported against this interface will be more comprehensible because they will (effectively) say that coords I am providing does not comply with ICoords. This is a contrived example, but this becomes more complex when you have deep compositions of zod types. This issue of typescript not using well named intermediate types when types are "extracted" from schema definitions like zod is what makes the error messages complex. This would not apply if typescript was to provide runtime type checking for interfaces defined in typescript (as opposed to them being inferred) because ts will have a way to "know" about these intermediate types. Then the type errors would not have to be always reported against the complex top level type.
- kristiandupont 3y agoThat's a good point. I just realized that I am working around this problem by explicitly setting a `z.Schema<...>` type: [link redacted]. The reason was to retain JSDoc comments on the types, but I guess this was another positive side effect. In any case, I agree with you that there is room for improvement.
- lf-non 3y agoAh ok. However, typescript is mostly smart enough to propagate comments [1] from zod schema properties to inferred types on its own. Thanks for maintaining kanel btw. We used to use this in a previous role alongside knex. It was very useful. [1] https://lorefnon.me/2022/06/25/generating-api-docs-for-zod-types/ https://lorefnon.me/2022/06/25/generating-api-docs-for-zod-t...
- kristiandupont 3y agoHah, I wasn't aware! I think that must have been fixed after I tried it the first time because I definitely concluded that it was necessary back then. And thank you for the kind words!