pick, omit, require & partial should use arrays instead of objects

[janpaepke]

I was wondering what the rationale behind pick, omit, require and partial expecting objects is?

Each value is optional and can only be true, so using

.pick(['foo', 'bar'])

feels more sensible than

.pick({ foo: true, bar: true })

There is another reason than convenience:
Currently you can (accidentally) add properties, which do not exist on the original object.
With an array you could ensure type safety.

The signature would look like this

pick<Mask extends Array<keyof T>>(mask: Mask): ZodObject<Pick<T, Extract<keyof T, keyof Mask>>, UnknownKeys, Catchall>;

If you agree I could offer to implement this.
Either in a backwards compatible way (also accepting objects, using overloads) or as a breaking change.

[igalklebanov]

There is another reason than convenience:
Currently you can (accidentally) add properties, which do not exist on the original object.
With an array you could ensure type safety.

Check out #1564, it's fixable.

[janpaepke]

Hi Igal,
thank you for your response and contribution for making unknown properties fail.
I am still wondering though about the rationale.
Why would we be using an object here? An array makes way more sense to me.

[BenWaNH]

I agree with @janpaepke
We'll shall always set prop to true
And it will be more easier to use, when receiving an array of pick props that we'll can set in pick method directly instead parse in object.

[janpaepke]

updated title and description, to include require and partial

Again: I am willing to add a PR for this, but want to understand the reason for using an object in the first place.

[janpaepke]

@colinhacks May I ask for your insight?

[capaj]

@janpaepke Prisma uses the same object notation for selecting fields.
IMHO it is easier to type correctly in typescript. I don't mind the extra verbosity, but you're right that doing pick({field: false}) doesn't make sense so using a Boolean might be a bit overkill.

Why not have both?

[colinhacks]

Too much of a footgun. Many many people will inevitably try this:

const keys = ['a', 'b'];

const schema = z.object({
  a: z.string(),
  b: z.string(),
  c: z.string()
}).pick(keys); // bad

Which is bad because Zod can't properly type the resulting schema, since the type signature of keys has collapsed to string[].

A similar problem exists for z.enum and it's caused a lot of headaches both for users and maintainers.

[Not-Jayden]

@colinhacks wondering if the const modifier might make this more feasible in the future? microsoft/TypeScript#51865

[colinhacks]

This syntax is already implementable without const, that's not the problem. It's just a footgun that will cause users frustration. This is the part that makes this syntax a footgun, and const doesn't fix that unfortunately.

[Not-Jayden]

Ah yep I misunderstood that part of the PR, my apologies.

[janpaepke]

Hi @colinhacks,

thanks for the feedback, that does make sense and I hadn't thought of that.
I will argue though that I still think it would be sensible to do.

Starting from your example: This wouldn't fail zod parsing, it would fail one step before, provided the function expects an array of the keys of T, as I wrote in my example in the original issue.

Then it would fail with something like

Argument of type 'string[]' is not assignable to parameter of type '(keyof T)[]'.
  Type 'string' is not assignable to type 'keyof T'.

This would point the user to the root of the issue (the type ambiguity of the provided array) and he can solve it in one of two ways:
A) providing the array inline .pick(['a', 'b'])
B) using const assertion: const keys = ['a', 'b'] as const; making the array readonly.

Use this to test:

type O = {
	a: number,
	b: string,
	c: boolean
}

const x = ['a', 'b'] as const

const pickTest = <T extends keyof O>(x: readonly T[]) => void x

pickTest(x);

Do you still think it is an inevitable footgun, or was I able to get you to at least consider to support both syntaxes?

[janpaepke]

@colinhacks I don't want to bother you with this, just make sure I understand your reasoning... Could you comment?

[tombburnell]

I noticed that the input keys to schema.omit(...) are not type checked (unless user error or my behalf). The following does not warn for me that "item" is spelt incorrectly.

schema.omit( { iteem: true }); // does not warn.

So I created the following omitKeys() function that creates the omit params { key => true } from a type-checked list:

function omitKeys(...keys: Array): { [key: string]: true } {
return Object.fromEntries(keys.map(key => [ key, true]));
}

Combined with an inferred interface, this allows passing type-checked input args as so..

export type ISchema = z.infer;
const reduced = schema.omit(omitKeys("iteem")); // this now does warn.

Ideally you could do something like the following and the interface inference just happens behind the scenes.

const reduced = schema.omit("key1", "key2");

But that might be hard so maybe you could add this method for convenience instead?

[tombburnell]

I've discovered my "solution" breaks the inferred interface of the resulting schema which just shows {} when using the interface.

Also if I only put one key in, it type checks it, but if I have multiple and one is fine, it does not. What could be happening here?

const reduced = schema.omit({
"optionn": true, // warns
});

const reduced = schema.omit({
"optionn": true, // does not warn, status is valid
"status": true,
});

const reduced = schema.omit({
"optionn": true, // warns - neither are valid
"statuss": true,
});

I'm using webstorm
"zod": "^3.22.4",
"typescript": "^5.1.6"

[tombburnell]

I see there is a ticket for this already.. #2607