3 ms·

Ditto. It took me a while (coming from C++) to get that types are not the ideal source of truth in TypeScript, due to their disappearance at runtime. Having a

Ditto. It took me a while (coming from C++) to get that types are not the ideal source of truth in TypeScript, due to their disappearance at runtime. Having a runtime parser (which can consequently express things impossible with TypeScript types alone, like "a positive integer" rather than being satisfied with any instance of `number`) from which types are inferred, is a needed mindset shift made easy with Zod. I use JSON Schemas for request validation and response serialisation (eg: [1]) in Fastify, derived from Zod parsers via zod-to-json-schema [2]. Some of Zod's runtime validation does not translate to JSON Schema (typically transforms), so YMMV. But this gives a good runtime glue with the static typing of request handlers. [1] https://github.com/SocialGouv/e2esdk/blob/beta/packages/server/src/routes/info.ts https://github.com/SocialGouv/e2esdk/blob/beta/packages/serv... [2] https://github.com/StefanTerdell/zod-to-json-schema https://github.com/StefanTerdell/zod-to-json-schema

eropple 4y ago
Maybe I was unclear - my post was a criticism of Zod because it involves a bunch of duct tape that I'm not sure makes sense. Typebox just creates JSON Schema objects at runtime and projects them into the type system with `Static<T>`. In so doing, you simultaneously create schema and types and the process of doing so is pleasant--you can just hand a TObject to Fastify as a validator object and you're done. Plus, with a Typebox type provider, it infers down to your handler. JSON Schema is the lingua franca; to me, working in it, rather than converting to it, is a much easier proposition.
- franky47 4y ago
  Interesting, I'll have a look, thanks!
- yencabulator 4y ago
  Zod has the same "simultaneously create schema and types and the process of doing so is pleasant" feature, it's just not using JSON Schema for it (and has more power than JSON schema does). In the Zod world, if you need JSON Schema to e.g. communicate to the outside world, you can extract it from the Zod schema with https://github.com/StefanTerdell/zod-to-json-schema https://github.com/StefanTerdell/zod-to-json-schema -- but if you don't, you don't. JSON Schema is kind of underpowered for real validation, so if you limit yourself to it, then you'll just have a another round of validation immediately after. TypeBox' s CreateType seems to be the same idea, it cannot be expressed in just JSON Schema.
  - eropple 4y ago
    I think Colin's a rad programmer, he works on EdgeDB which is absolutely my favorite datastore I've ever used and I think Zod's fine if you want to use it. But I don't agree with your premise. I don't, in practice, find the way Zod asks you to think about data compelling. It's probably because I think specifically in communication between systems; making the particulars of the interchange format central to the act of writing the thing, for me, keeps top-of-mind the necessity of both ends having an identical understanding of the allowable semantics. (Similarly, I've never used any Typebox features that don't map to JSON Schema, and I've never felt the need to.)
pcthrowaway 4y ago
If you're going from Zod parsers to JSON schema, are you duplicating that in Typescript? Or can you just go ts-to-zod[1] then zod-to-json-schema? [1]: https://github.com/fabien0102/ts-to-zod https://github.com/fabien0102/ts-to-zod
- franky47 4y ago
  Zod schemas are the source of truth, from which TS types are inferred and JSON schemas are generated.
  - pcthrowaway 4y ago
    Interesting.. I'd rather write typescript types than Zod schemas. I haven't used JSON schema, but going TS to Zod was straightforward and really pleasant
    - zarzavat 4y ago
      Typescript can't understand types as objects, but it can understand objects as types (using typeof). So starting with objects and generating types is more natural. Also if you start with objects you can express runtime conditions that are not possible with types, for example maximum sizes. Zod is quite a bit more general than JSON schema because it can express transformations not just validations.
    - yencabulator 4y ago
      That way does not give you runtime validation of input. (Or, requires an extra build step to generate that. It's beyond Typescript itself.)

eropple 4y ago

Maybe I was unclear - my post was a criticism of Zod because it involves a bunch of duct tape that I'm not sure makes sense. Typebox just creates JSON Schema objects at runtime and projects them into the type system with `Static<T>`. In so doing, you simultaneously create schema and types and the process of doing so is pleasant--you can just hand a TObject to Fastify as a validator object and you're done. Plus, with a Typebox type provider, it infers down to your handler. JSON Schema is the lingua franca; to me, working in it, rather than converting to it, is a much easier proposition.

franky47 4y ago
Interesting, I'll have a look, thanks!
yencabulator 4y ago
Zod has the same "simultaneously create schema and types and the process of doing so is pleasant" feature, it's just not using JSON Schema for it (and has more power than JSON schema does). In the Zod world, if you need JSON Schema to e.g. communicate to the outside world, you can extract it from the Zod schema with https://github.com/StefanTerdell/zod-to-json-schema https://github.com/StefanTerdell/zod-to-json-schema -- but if you don't, you don't. JSON Schema is kind of underpowered for real validation, so if you limit yourself to it, then you'll just have a another round of validation immediately after. TypeBox' s CreateType seems to be the same idea, it cannot be expressed in just JSON Schema.
- eropple 4y ago
  I think Colin's a rad programmer, he works on EdgeDB which is absolutely my favorite datastore I've ever used and I think Zod's fine if you want to use it. But I don't agree with your premise. I don't, in practice, find the way Zod asks you to think about data compelling. It's probably because I think specifically in communication between systems; making the particulars of the interchange format central to the act of writing the thing, for me, keeps top-of-mind the necessity of both ends having an identical understanding of the allowable semantics. (Similarly, I've never used any Typebox features that don't map to JSON Schema, and I've never felt the need to.)

pcthrowaway 4y ago

If you're going from Zod parsers to JSON schema, are you duplicating that in Typescript? Or can you just go ts-to-zod[1] then zod-to-json-schema? [1]: https://github.com/fabien0102/ts-to-zod https://github.com/fabien0102/ts-to-zod

franky47 4y ago
Zod schemas are the source of truth, from which TS types are inferred and JSON schemas are generated.
- pcthrowaway 4y ago
  Interesting.. I'd rather write typescript types than Zod schemas. I haven't used JSON schema, but going TS to Zod was straightforward and really pleasant
  - zarzavat 4y ago
    Typescript can't understand types as objects, but it can understand objects as types (using typeof). So starting with objects and generating types is more natural. Also if you start with objects you can express runtime conditions that are not possible with types, for example maximum sizes. Zod is quite a bit more general than JSON schema because it can express transformations not just validations.
  - yencabulator 4y ago
    That way does not give you runtime validation of input. (Or, requires an extra build step to generate that. It's beyond Typescript itself.)