Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zod 4

zod.dev

Post reply on HN
Print view View original

131–140 of 260 posts

Re: Zod 4

#131

Post by elbajo »

colinmcd wrote: post #125

Author here, AMA! Regarding the versioning: I wrote a fairly detailed writeup here[0] for those who are interested in the reasons for this approach. Ultimately npm is not designed to handle the situation Zod finds itself in. Zod is subject to a bunch of constraints that virtually no other libraries are subject to. Namely, the are dozens or hundreds of libraries that directly import interfaces/classes from Zod and use…

First thank you for the hard work, many of my local hacks will go away with the new features!

As a convenience and mostly avoid typos in form names I use my own version of https://github.com/raflymln/zod-key-parser. I've been surprised something like this hasn't been implemented directly in the library.

Curious if you think this is out of scope for Zod or just something you haven't gotten around to implement?

(Here are discussions around it: https://github.com/colinhacks/zod/discussions/2134)

Re: Zod 4

#132

Post by mmcnl »

skydhash wrote: post #118
diggan wrote: post #113

Earlier quoted context omitted.

> why keep both old and new code together like a Frankeinstein project? It seems like Zod is a library that provides schema to your (domain) objects in JS/TS projects, so if you're all-in with this library, it's probably a base-layer for a ton of stuff in the entire codebase. Now imagine that the codebase is worked on by multiple parties, in different areas, and you're dealing with 100K-1M lines of code. Realisticall…

If it's part of your core domain, I'd say that one of the reasons you want the feature set and the API to be as stable as possible. And your core domain should probably be isolated from the things that depends on it in such way that only business logic ripples out. One of the strange things from the NPM/JS culture is the focus to write everything in one language leading to everyone forgetting about modularization and…

This comment feels very detached from reality. Migrating core dependencies in large projects is always cumbersome. One universal truth is that you can make complex tasks easy by breaking it up into small pieces. Providing a sensible forward migration path like what Zod does causes 0 harm and makes everyone's life easier. This has absolutely nothing to do with "NPM/JS" culture, whatever that means.

Re: Zod 4

#133

Post by brulard »

devin wrote: post #7

Seeing an announcement for a new version of some typescript library I've never heard of shoot to the top of the front page makes me feel extremely out of touch with mainstream dev.

Zod is quite common, if not the most used validation library for JS/TS projects.

Re: Zod 4

#134

Post by mmcnl »

johnfn wrote: post #20

I'm curious if anyone here can answer a question I've wondered about for a long time. I've heard Zod might be in the right ballpark, but from reading the documentation, I'm not sure how I would go about it. Say I have a type returned by the server that might have more sophisticated types than the server API can represent. For instance, api/:postid/author returns a User, but it could either be a normal User or an anon…

Your server should export the types. Don't write types by hand in your client, that makes no sense. The server knows what data it is sending and should provide that information as metadata to the client. Practically this can mean that a Python backend uses Pydantic schemas which can be used to automatically generate an OpenAPI specification that your client can use to generate types.

Re: Zod 4

#135

Post by johnfn »

joshfee wrote: post #87
johnfn wrote: post #75

Earlier quoted context omitted.

I think I can do this, yes, but it becomes a very large amount of repetitive work. Let's say I have api/profile (which has `.posts`) and api/user-directory (which does not). I define User as a discriminated union - one has type `user-with-posts` and one has type `user-no-posts`. OK, good so far. But now say I have a photo gallery, which returns photos on user. Now I have to add that into my discriminated union type,…

You can use a string union to discriminate when it makes sense, but that's not the only way to discriminate and in this case you'd instead use the presence of the items themselves (essentially duck-typing with strong type guarantees) Typescript playground: https://www.typescriptlang.org/play/?#code/C4TwDgpgBACg9gZ2F...

Now you run into the issue I mentioned in GP, where you end up writing `if (blah)` everywhere, even though you know that `blah` is definitely present.

Re: Zod 4

#136

Post by transitivebs »

colinmcd wrote: post #125

Author here, AMA! Regarding the versioning: I wrote a fairly detailed writeup here[0] for those who are interested in the reasons for this approach. Ultimately npm is not designed to handle the situation Zod finds itself in. Zod is subject to a bunch of constraints that virtually no other libraries are subject to. Namely, the are dozens or hundreds of libraries that directly import interfaces/classes from Zod and use…

this blog post was a delight to read. great work, colin && thanks!!

Re: Zod 4

#137

Post by colinmcd »

elbajo wrote: post #131
colinmcd wrote: post #125

Author here, AMA! Regarding the versioning: I wrote a fairly detailed writeup here[0] for those who are interested in the reasons for this approach. Ultimately npm is not designed to handle the situation Zod finds itself in. Zod is subject to a bunch of constraints that virtually no other libraries are subject to. Namely, the are dozens or hundreds of libraries that directly import interfaces/classes from Zod and use…

First thank you for the hard work, many of my local hacks will go away with the new features! As a convenience and mostly avoid typos in form names I use my own version of https://github.com/raflymln/zod-key-parser . I've been surprised something like this hasn't been implemented directly in the library. Curious if you think this is out of scope for Zod or just something you haven't gotten around to implement? (Here…

Some kind of affordance for FormData/URLSearchParams-style structures is definitely in scope. It was a late cut. Ultimately HTML inputs/forms are an implicit type system unto itself—certainly HTML has a very different notion of "optional" than TypeScript. So my approach to this would likely involve another sub-library ("zod/v4-form").

I like your library! Put in a PR to add it to the ecosystem page :)

Re: Zod 4

#138

Post by jjice »

colinmcd wrote: post #125

Author here, AMA! Regarding the versioning: I wrote a fairly detailed writeup here[0] for those who are interested in the reasons for this approach. Ultimately npm is not designed to handle the situation Zod finds itself in. Zod is subject to a bunch of constraints that virtually no other libraries are subject to. Namely, the are dozens or hundreds of libraries that directly import interfaces/classes from Zod and use…

Big thank you for the work on Zod - it's a fantastic library and it's been incredibly valuable for data validation/parsing in Node environments for me over the last two years.

Re: Zod 4

#139

Post by colinmcd »

skydhash wrote: post #110
gejose wrote: post #56

Earlier quoted context omitted.

> Peer dependencies are so broken that they had to make v4 pretend it's v3 I'm not sure this is the right conclusion here. I think zod v4 is being included within v3 so consumers can migrate over incrementally. I.e refactor all usages, one by one to `import ... from 'zod/v4'`, and once that's done, upgrade to v4 entirely.

How do you even migrate incrementally? why keep both old and new code together like a Frankeinstein project? Especially on a codebase you own. It's a library, not a platform.

This is not done for Zod's benefit. It's done for the benefit of libraries that depend on Zod, and the users of those libraries. If a library wants to add "incremental" support for Zod4 (that is, without dropping support for Zod 3 and publishing a new major), they need access to types (and possibly runtime code) from both libraries to do so in a sound way. I detail a number of other approaches for achieving this here[0] and why they ultimately fall short. Ultimately npm wasn't designed for this particular set of circumstances.

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

Re: Zod 4

#140

Post by Sammi »

skydhash wrote: post #118
diggan wrote: post #113

Earlier quoted context omitted.

> why keep both old and new code together like a Frankeinstein project? It seems like Zod is a library that provides schema to your (domain) objects in JS/TS projects, so if you're all-in with this library, it's probably a base-layer for a ton of stuff in the entire codebase. Now imagine that the codebase is worked on by multiple parties, in different areas, and you're dealing with 100K-1M lines of code. Realisticall…

If it's part of your core domain, I'd say that one of the reasons you want the feature set and the API to be as stable as possible. And your core domain should probably be isolated from the things that depends on it in such way that only business logic ripples out. One of the strange things from the NPM/JS culture is the focus to write everything in one language leading to everyone forgetting about modularization and…

You use Zod to define all the schemas and types used in "your core domain". It is the base layer tool of your business logic and models, and for defining your interfaces. And yes it makes it possible to share all of this between the frontend and backend, which is a tremendous improvement in both correctness and in development productivity.

You don't get anything remotely like this in any other backend frontend combo.

Post reply on HN