Hacker News Reader

Comment by 9dev | Hacker News Reader

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.

View on HN

…or just use Zod?

And if you like Zod, you might as well use this: https://github.com/asteasolutions/zod-to-openapi

It converts Zod types to OpenAPI specification.

Or json schema, this https://www.npmjs.com/package/zod-to-json-schema

Json schema is more universal, and it can be used in .NET, Java, etc.

Yeah, that’s what I was thinking of. There are a few alternatives though, so I referred to existing tooling in general.

I 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.

I like the sentiment, but you’ve gotta admit that being able to skip the “generation” step has its benefits

The 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.

Everybody 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.

Reply on news.ycombinator.com