What does HackerNews think of zod?

TypeScript-first schema validation with static type inference

Language: TypeScript

tRPC – Build and consume typesafe APIs without schemas or code generation | Aug 2023

Overzealous Destructuring | Oct 2022

> it’s important to remember that TypeScript does not provide any assurances about a variable’s runtime type, especially if the data is coming from an external source (like an API). In those cases, you often need to use type assertions or guards anyway to assert the returned type because TypeScript can’t infer the type of dynamically fetched data. So destructuring the data is more dangerous than defensive coding (like using the optional chaining operator or good-old if statements).

Optional chaining or null checks should not be used "defensively". They should just be used whenever TypeScript tells you to. Otherwise you just exacerbate the problem and end up with more unanticipated null values.

If you're dealing with an API with untrustworthy types or lots of null values, the solution is to:

a) Write mostly optional type definitions for that API, and/or

b) Use zod to verify the API data before you use it, to make sure it matches your expectations.

https://github.com/colinhacks/zod

Aleph.js – Fullstack Framework in Deno | Jun 2022

You probably don’t want that throughout your entire codebase. It’s a lot of overhead. Where you do want it (at API/user input/network etc boundaries), you can use something like Zod[1] or similar to define your type guards and then infer the static types from there.

1: https://github.com/colinhacks/zod

FormKit: Form building framework for Vue 3 | May 2022

Expand Context ↕

I didn’t know that a lot of these schema systems use eval. Surprising, why is that?

As far as I can tell, my go-to schema system doesn’t. https://github.com/colinhacks/zod

Server Side Rendering at scale | Feb 2022

Expand Context ↕

Simple things like validating incoming payloads are made ridiculously complex. You can get a library to do that, but which do you use? And then most of them don't export the typescript type signature so you don't get any type safety unless you re-define the type in typescript.

I strongly recommend Zod[0]. You write your schemas in code, it validates incoming JSON at runtime, and you end up with either an error or well typed code. The schemas themselves are powerful (you can check properties of strings, etc), and the derived typescript type comes out for free and looks like a human wrote it. A very powerful tool, with a very intuitive interface.

Give elixir a serious go and see if you ever say this again.

Ah you hit me where it hurts - really need to seriously try the Erlang ecosystem.

[0]https://github.com/colinhacks/zod

From TypeScript to ReScript | Jan 2022

Expand Context ↕

You can accomplish it with a library like zod[1]. It's not the prettiest though; first class support would definitely be better.

1 - https://github.com/colinhacks/zod

Deno Joins TC39 | Dec 2021

Expand Context ↕

This would be a big (but exciting) departure from the current TS goal of "Impose no runtime overhead on emitted programs." [1]

Recently, I've been using Zod [2] and find it to be a satisfying equivalent: you define a schema, and then you get both a TS type AND a JS parser/validator (which works as a TS typeguard).

[1] https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi... [2] https://github.com/colinhacks/zod

Tips For Making a Popular Open Source Project in 2021 | Nov 2021

I have two projects with a total of almost 7k stars. [0]

It’s worth noting that GitHub stars truly don’t translate into anything worthwhile in the vast majority of cases. You can have a massively popular project, but it doesn’t automatically translate into Twitter followers or newsletter subscribers. And those things don’t directly translate into wealth or happiness either.

Just get a job and make friends and have a life. That route has the highest expected value. I have been chasing GitHub stars for a long time, and it has never been fulfilling. I wouldn’t recommend it.

[0] https://github.com/colinhacks/zod

JSON Schema bundling finally formalised | Sep 2021

Expand Context ↕

You can write validation schemas using zod library [1]. They end up looking pretty similar to typescript definitions (same vocabulary, same methods for combining/intersecting/filtering). And if you migrate to typescript you'll get type definitions for free out of those schemas.

[1] https://github.com/colinhacks/zod

Testing in production: using JSON Schema for 3rd party API response validation | Aug 2021

I tried to introduce `zod` (https://github.com/colinhacks/zod) to achieve the same thing within my current team.

The idea was that API responses that weren't reflected in the types would cause hard errors that we had to fix, and that we'd be forced to make sure that the mocks in our tests were up-to-date valid responses. Similarly to the article, I also made it so that in production they would log warnings, because I didn't want to expose us to the possibility that validation could take down the app.

However, TypeScript is new to my current team, and so nobody wanted the introduction of a validation API on top. It ended up being ~20 lines of code I couldn't get merged. Since TypeScript was new to the team syntax like `z.infer`, generic code and a whole new way to define types at runtime made them feel like it was too complicated.

Did others have similar problems introducing something like this?

Parsix: Parse Don't Validate | May 2021

Not exactly what you want, I think, but there is zod [0].

I really would like to see nominal typing support in TypeScript. Currently, it's hard to validate a piece of data (or parse for that matter) once and have other functions only operate on that validated data. There are (ugly?) workarounds though [1].

[0]: https://github.com/colinhacks/zod [1]: https://gist.github.com/dcolthorp/aa21cf87d847ae9942106435bf...