Simplifying 'null' Handling in Zod with a Cleaner Approach

[semanticist21]

I've been using Zod for API validation in corporate projects, and handling null has always been a frustrating experience. I believe Zod should provide a shorthand function for .nullish().transform(x => x ?? undefined) to make this process cleaner.

Why is null an Issue?

In many programming languages, undefined doesn’t exist, but in JavaScript, null is often used as an intentional empty value. However, when dealing with APIs, 99% of the null values I encounter are just placeholders and should be treated as undefined.

When defining optional fields in API specifications, .nullish() helps, but it doesn’t fully resolve the issue. Since I rely on Zod for most preprocessing and postprocessing, dealing with nullish repeatedly becomes a tiresome task.

Problems with the Current Approach

1. Repetitive .transform() Calls

Every time I use .default(), I also need to manually apply .transform(). Imagine doing this across 50+ files with complex data structures.

// Without handling null
const memberInfoSchema = z.object({
  name: z.string().default('unknown')
});

// Required transformation for nullish values
const memberInfoSchema = z.object({
  name: z.string().nullish().transform((v) => v ?? 'unknown')
});

2. Type Compatibility Issues

Null values also introduce inconsistencies when working with TypeScript interfaces.

const memberInfoSchema = z.object({
  name: z.string().nullish(),
});

const data: z.infer<typeof memberInfoSchema> = {
  name: 'unknown',
};

const SomeComponent = ({ name }: { name?: string }) => {
  return <div>{name}</div>;
};

// Type error occurs because `data.name` might be null
<SomeComponent name={data.name} />;

// Workaround: Explicitly handle null
<SomeComponent name={data.name ?? undefined} />;