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

151–160 of 260 posts

Re: Zod 4

#151

Post by Sammi »

johnfn wrote: post #59
stephen_hn wrote: post #42

Earlier quoted context omitted.

I think you would use discrimated unions. const MyResult = z.discriminatedUnion("status", [ z.object({ status: z.literal("success"), data: z.string() }), z.object({ status: z.literal("failed"), error: z.string() }), ]); You can define passthrough behavior if there are a bunch of special attributes for a moderator but you don't want to list/check them all. With different methods that have different schema- If they sha…

Hmm, this is pretty interesting, but I still have issues. While Zod seems to be able to transform my server-returned object into a discriminated union, it doesn't seem to be able to tell which of the unions it is. For instance, say that api/user/mod-panel (e.g.) returns only moderator user objects. My API endpoint already knows that it will have moderator-related fields, but Zod forgets that when I parse it.

You can define all the different sub types separately and make the discriminated union using them. The use only a single type for an endpoint if it only uses a single type. Only use the discriminated union where you actually might be handling multiple types.

Re: Zod 4

#152

Post by skydhash »

danenania wrote: post #121
Trufa wrote: post #111

Earlier quoted context omitted.

I feel like people will upvote anything negative. This is not much a limitation of npm, there's nothing intrinsically wrong with npm that lead to this decision, this is more a pragmatic way of allowing progressive change of a library that introduced a lot of braking changes.

Right, you have the same issues to consider when shipping a breaking major version upgrade to a new library in any language/ecosystem. That said, you do see a cultural difference in node-land vs. many other ecosystems where library maintainers are much quicker to go for the new major version vs. iterating on the existing version and maintaining backward compatibility. I think that's what people are mostly really refe…

This very much. If I'm using your library, I've already committed to it's architecture and API with all its flaws. And my users don't care for the technology I use. Even if they're not that good, I can build wrapper over the worst aspects and then just focus on building features. New features are nice, but I'm more interested in getting security updates for the current version that I have.

When it's time to go for a refactoring, the trade-off between costs and returns are worth it as you can go for years between those huge refactors.

Re: Zod 4

#153

Post by bobbyraduloff »

great job on zod. it’s an incredible library. also really excited about the locale errors. finally I can push the zod errors directly to the frontend. would love to take responsibility for the BG locale.

Re: Zod 4

#154

Post by hombre_fatal »

skydhash wrote: post #114
hombre_fatal wrote: post #102

Earlier quoted context omitted.

Django doesn't run in the browser though. All of the tech they listed can run in the browser which gives you other superpowers at the expense of having moving targets, but that's what they opted into when they decided to run code on user machines instead of in a single server environment.

The main browser API is pretty stable, all things considered. It's just that people can't seem to stay put on a given design, instead trying everything under the sun. When you have something like SDL which is at it's third version at 27 years old, I'm very doubtful about the culture of NPM/JS world. A closer example is jQuery which is also in its third version at 18 years old.

True, the browser API might be stable, but the best way to build stateful client applications is unstable.

It's a constantly improving and experimental domain - not just on the web but also the desktop and mobile environment.

Next.js is a good example since it (and its competitors) are a natural iteration on top of SPAs where you want the first request to the server to also inline the initial state of the SPA to remove the double-request problem.

But you pay a huge price trying to live on the edge like that, and when you run into issues, it doesn't make much sense to call that the state of web development since you could have used boring server tech or even a boring React SPA which also hasn't changed much in a decade.

Re: Zod 4

#155

Post by Lvl999Noob »

colinmcd wrote: post #122
rafram wrote: post #39

> To simplify the migration process both for users and Zod's ecosystem of associated libraries, Zod 4 is being published alongside Zod 3 as part of the zod@3.25 release. [...] import Zod 4 from the "/v4" subpath npm is an absolute disaster of a dependency management system. Peer dependencies are so broken that they had to make v4 pretend it's v3.

Author here. I wrote a fairly detailed writeup here[0] for those who are interested in the reasons for this approach. Ultimately you're right that npm doesn't work well to manage the situation Zod finds itself in. But Zod is subject to a bunch of constraints that virtually no other libraries are subject to. There are dozens or hundreds of libraries that directly import interfaces/classes from "zod" and use them in th…

Are there any plans of doing an actual v4 release and making zod/v4 the default there? Perhaps make simulatenous releases of zod v3 containing a /v4 path and a zod v4 containing a /v3 path? Then converge on just zod v4 with no /v3 from 4.1 onwards.

Re: Zod 4

#156

Post by causal »

blackoil wrote: post #71
causal wrote: post #5

Zod is a lot better than some of the alternative solutions I've seen. That said, the need for this sort of explicit validation always felt like a failure of where modern web development has taken us. It's so frustrating how full-stack development requires so many ways of describing the same shapes: JS input validation, Swagger for API definition, server-side input validation, ORM for schema conformance, and TypeScrip…

We use drizzle + Hono + client with zod. So the entire chain from ui to client to server to DB follow same validation and shape.

I've heard of this stack, glad to hear it works, still hate that you need three separate external dependencies to do it

Re: Zod 4

#157

Post by elbajo »

colinmcd wrote: post #137
elbajo wrote: post #131

Earlier quoted context omitted.

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 :)

Great to hear this is something you are considering!

To be clear: this isn't my library. This is just something I found while trying to solve the FormData issue. Props go to https://github.com/raflymln who created it.

Re: Zod 4

#158

Post by skydhash »

Sammi wrote: post #147
diggan wrote: post #116

Earlier quoted context omitted.

One possible solution: Publish a new package with a new name. I've personally been thinking of doing that for some libraries, where I'd commit to never change the public API, and if I figure out a nicer way of doing something, I'd create a new library for it instead, and people who wanna use/maintain the old API can continue to do so.

People wouldn't change to the new one, because names are extremely sticky, so what's the point?

If they need the new one, they will switch to it. And you have the right to drop support for the old one after a while (hopefully giving everyone the time to migrate).

Re: Zod 4

#159

Post by diggan »

Sammi wrote: post #147
diggan wrote: post #116

Earlier quoted context omitted.

One possible solution: Publish a new package with a new name. I've personally been thinking of doing that for some libraries, where I'd commit to never change the public API, and if I figure out a nicer way of doing something, I'd create a new library for it instead, and people who wanna use/maintain the old API can continue to do so.

People wouldn't change to the new one, because names are extremely sticky, so what's the point?

Ok, that's fine by me. They can continue using the original library for whatever reason they want, including because of the name.

Re: Zod 4

#160

Post by dmkolobov »

skydhash wrote: post #148
Sammi wrote: post #140

Earlier quoted context omitted.

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.

I get the wish to have that, but IMO, it's a flawed approach. The frontend and the backend are generally different domains. Initially, their model may look alike, but they will probably differs during the lifetime of the project as they serve different needs. That's why the shape of the data stored in the DB differs from the one involved in business logic, which differs from the DTOs, which can differs from the objec…

The point is that somewhere, you need to chuck bytes over the network and someone needs to receive them.

If the teams working on the two are different, or even if the expertise level is uneven, something like a typed serialization library is a great boon.

At work, I maintain a Haskell-like programming language which spits out JSON representations of charts over OLAP queries. I’m the only one who knows the language extensively, but everyone is expected to do work with the JSON I push. If I serialize something incorrectly, or if someone else mistypes the frontend JSON response definition, we’re in for a world of pain.

Needless to say, I’ll be adding something like Zod to make that situation safer for everyone.

Post reply on HN