nonNullable to disallow null

[sezanzeb]

z.any().nonNullable()
z.nonNullable(z.any())

can both be now used to make this throw:

z.any().nonNullable().parse(null)

This is not equivalent to unwrap (as proposed in #2190). Instead, this is equivalent to typescripts NonNullable type https://www.typescriptlang.org/docs/handbook/utility-types.html#nonnullabletype

[netlify]

✅ Deploy Preview for guileless-rolypoly-866f8a ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	a54ef93
🔍 Latest deploy log	https://app.netlify.com/sites/guileless-rolypoly-866f8a/deploys/660c24129f466b00089a9566
😎 Deploy Preview	https://deploy-preview-3141--guileless-rolypoly-866f8a.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[colinhacks]

I appreciate the PR, but this is a little too niche to go into Zod core. This is better implemented with a transform.

const A = z.string().nullable().transform((val, ctx) => {
  if(val === null) {
    ctx.addIssue({
      code: z.ZodIssueCode.custom,
      message: "Cannot be null",
      path: [],
    })
    return z.NEVER;
  }
  return val;
})

type A = z.infer<typeof A>;
// string

[sezanzeb]

I obviuosly disagree, otherwise I wouldn't have made the PR. It would have come handy at work when I decided to work on this.

Furthermore it is compliant with typescripts NonNullable, and not a funky Idea that I just made up. So if NonNullable would ever be a thing, it would be in the way this PR proposes.

The typescript developers didn't think a NonNullable type is too niche to add it to typescript.

Transformers are flexible, but they are not nearly as readable and beautiful like the zods other features.

And also, this addition already has automated tests and is fully documented. This is a finished feature that doesn't add immediate development overhead for you. It's as good as it gets.

[sezanzeb]

I think zod should be made as similar to typescripts types as possible. I want to be able to replace all interfaces and such with zod types with beautiful zod structures. Therefore, I think as many of typescripts built ins (like NonNullable) should be replicated in zod.

Well, my 2 cents.

[sezanzeb]

I guess I should also add that I didn't encounter a situation in which I wanted to use this since making the PR, maybe someone else should comment on this instead. I can't give you a realistic estimate on how commonly this feature would be used. On the other hand, there are tons of other existing zod features that I didn't consider using since then as well, so...

[michaelhays]

What's more is the transform workaround here doesn't seem to work for me with z.any(), as nestedValue is still optional:

const schema = z.object({
  nestedValue: z
    .any()
    .nullable()
    .transform((val) => (val == null ? z.NEVER : val)),
})

type SchemaType = z.infer<typeof schema>

type SchemaType = {
  nestedValue?: any;
}

[sezanzeb]

nonNullable also restricts undefined (https://www.typescriptlang.org/docs/handbook/utility-types.html#nonnullabletype)

It's as good as it gets.

That aged well

committed the change.

---

use case: A gateway passes along all payloads it gets, and it doesn't care for their content, but it does check if the payloads are set by using z.unknown().nonNullable()

[colinhacks]

nonNullable also restricts undefined

The fact that .nonNullable() would not be the inverse of .nullable() is a big footgun. But adding a .notNullable() method that disagrees with the NonNullable built-in is also a footgun. Two bad options, imo, so it's not likely I take any action here I'm afraid.

[sezanzeb]

Something that I would like to do quite often:

class A {
  private foo: whatever | null = null;
  
  // ... some stuff that eventually sets foo ...

  public bar() {
    z.nonNullable().parse(this.foo).whateversMethod()
  }
}

You could also add an assertion method there (which isn't actually typesafe at all), or a guard clause that checks for === null and throws an error conditionally, but in many cases I prefer to use zod for such things.

Yes, using zod here has also drawbacks, but it's still something that I feel like would be a nice thing to do.

While the code above would already throw an error without zod, typescript will refuse to compile it without zod or a guard.

zod has, in many cases, become something like quick-and-dirty runtime-type-validation for me.

Just thought I might throw in some more thoughts on this, but no harsh feelings if this is still considered problematic and not merged.