4 ms·
Yes, I was wondering about that too. If you put in the effort to parse the docblock into runtime validation, why not pick up the existing utilities to convert T
by 9dev 3y ago
Yes, I was wondering about that too. If you put in the effort to parse the docblock into runtime validation, why not pick up the existing utilities to convert TypeScript types into runtime code during the build? That would be much more powerful, with the added benefit of having type safety for all other code, and a familiar syntax for developers.
- ushakov 3y ago…or just use Zod?
- Ciantic 3y agoAnd if you like Zod, you might as well use this: https://github.com/asteasolutions/zod-to-openapi https://github.com/asteasolutions/zod-to-openapi It converts Zod types to OpenAPI specification.
- vmfunction 3y agoOr json schema, this https://www.npmjs.com/package/zod-to-json-schema https://www.npmjs.com/package/zod-to-json-schema Json schema is more universal, and it can be used in .NET, Java, etc.
- 9dev 3y agoYeah, that’s what I was thinking of. There are a few alternatives though, so I referred to existing tooling in general.
- madeofpalk 3y agoI don't like writing type definitions with zod's DSL. I want to write definitions in the "first party syntax" - which both JSDoc and Typescript types are - and have everything else generated out from that.
- purplerabbit 3y agoI like the sentiment, but you’ve gotta admit that being able to skip the “generation” step has its benefits
- madeofpalk 3y agoThe only way to can skip that generation is if the zod type is your primary schema, which is only possible if your API is in javascript.
- yencabulator 3y agoEverybody seems to want that, except for the people who work on Typescript, who argue it'd be the wrong tool. Typescript's types simply aren't able to provide input validation, both because they don't exist at runtime and for lack of power ("number must be 0..10"). At least with Zod, you also get Typescript types, from the same schema.
- deleted 3y ago[deleted]