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

31–40 of 260 posts

Re: Zod 4

#31

Post by adpirz »

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…

It's hard to unpack without knowing more about the use case, but adding discriminant properties (e.g. "user_type") to all the types in the union can make it easier to handle the general and specific case.

E.g.

if (user.user_type === 'authenticated') {

  // do something with user.name because the type system knows we have that now

}

Re: Zod 4

#32

Post by satvikpendem »

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.

If you don't do web dev (or at least, the latest web dev) then it's understandable, I often see lots of posts in the top spots whose languages I have no idea about either.

Re: Zod 4

#33

Post by ashwinsundar »

jilles wrote: post #23
ar-nelson wrote: post #15

Obligatory shameless plug whenever Zod is posted: if you want similar, but much more minimal schema validation at runtime, with a JSON representation, try Spartan Schema: https://github.com/ar-nelson/spartan-schema

When I see a repository with many files "updated 4 years ago" I'm usually inclined to think it's abandoned.

Or the code is done and doesn’t need to be iterated on continuously?

Re: Zod 4

#34

Post by 90s_dev »

esafak wrote: post #14
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.

What do you use for validation in TS? Anyone who deals with data should be validating/parsing it.

  const cached = new Map()

  export function as(o: any, path: string, as: (o: any) => T | undefined) {
    try {
      let fn = cached.get(path)
      if (!fn) cached.set(path, fn = new Function('o', `return o.${path}`))
      const v = fn(o)
      return as(v) as T | undefined
    }
    catch (e) {
      return undefined
    }
  }

  as.number = (o: any) => (typeof o === 'number' ? o : undefined)
  as.string = (o: any) => (typeof o === 'string' ? o : undefined)
  as.boolean = (o: any) => (typeof o === 'boolean' ? o : undefined)
  as.numbers = (len = 0) => (o: any) => (o instanceof Array && o.length >= len && o.every(c => typeof c === 'number') ? o : undefined)
  as.strings = (len = 0) => (o: any) => (o instanceof Array && o.length >= len && o.every(c => typeof c === 'string') ? o : undefined)


  const size = as(usrConfig, 'sys.size', as.numbers(2))
  const fontpath = as(usrConfig, 'sys.font', as.string)

Re: Zod 4

#35

Post by 8s2ngy »

Congratulations to the Zod team on the new release. At the risk of sounding overtly negative, I can't help but shudder when I think about the number of breaking changes outlined in the migration guide. For projects that rely heavily on Zod, it feels like a daunting task ahead—one that will demand a lot of developer attention and time to navigate. Having maintained a few frontend projects that are 4-5 years old at work, I really empathize with them.

In my experience, large React projects often depend on a multitude of libraries, and when each one rolls out substantial changes—sometimes with barely any documentation—it can quickly become overwhelming. This is honestly one of my least favorite aspects of working with JavaScript. It just feels like a constant uphill battle to keep everything in sync and functioning smoothly.

Re: Zod 4

#36

Post by satvikpendem »

neilpa wrote: post #4

We're currently evaluating both Zod and ArkType as a replacement for earlier JSON schema validations. The thing I can't get over with Zod is the syntax is _so_ different from defining TS types. Are there reasons to go with Zod over ArkType?

We also chose ArkType after evaluating Zod, Valibot, and Effect Schema, among others. It seemed to have the best developer experience while also being much faster. It also supports the Standard Schema project which I believe Effect Schema does not fully support.

Re: Zod 4

#37

Post by probabletrain »

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…

In an ideal world you'd have one source of truth for what the shape of a User could be (which may well be a discriminated union of User and AnonymousUser or similar).

Without fullstack TS this could look something like: (for a Python backend) Pydantic models+union for the various shapes of `User`, and then OpenAPI/GraphQL schema generation+codegen for the TS client.

Re: Zod 4

#38

Post by koakuma-chan »

8s2ngy wrote: post #35

Congratulations to the Zod team on the new release. At the risk of sounding overtly negative, I can't help but shudder when I think about the number of breaking changes outlined in the migration guide. For projects that rely heavily on Zod, it feels like a daunting task ahead—one that will demand a lot of developer attention and time to navigate. Having maintained a few frontend projects that are 4-5 years old at wor…

> For projects that rely heavily on Zod, it feels like a daunting task ahead—one that will demand a lot of developer attention and time to navigate.

Or just use an LLM.

Re: Zod 4

#39

Post by rafram »

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

Re: Zod 4

#40

Post by camgunz »

koakuma-chan wrote: post #38
8s2ngy wrote: post #35

Congratulations to the Zod team on the new release. At the risk of sounding overtly negative, I can't help but shudder when I think about the number of breaking changes outlined in the migration guide. For projects that rely heavily on Zod, it feels like a daunting task ahead—one that will demand a lot of developer attention and time to navigate. Having maintained a few frontend projects that are 4-5 years old at wor…

> For projects that rely heavily on Zod, it feels like a daunting task ahead—one that will demand a lot of developer attention and time to navigate. Or just use an LLM.

And then pick through all the LLM's mistakes.
Post reply on HN