Schemas generated by refine do not have the omit method (or that is what typescript says)

Hello, first of all, thanks for Zod, it’s fantastic. According to typescript, the objects that have been refined do not have the omit method. To reproduce you can try something as simple as this

const schema = z.object({ name: z.string(), age: z.number() }).refine(() => true);
const newSchema = schema.omit({ name: true }) // <- omit does not exist 

[danielo515]

Is this a bug or expected behavior? If it is the latter, can it we changed?

[scotttrinh]

Yeah, I know this seems not optimal, but it keeps everything explicit in a way that arbitrarily adding effects on defined schemas did not. There is a whole long history and context here: https://github.com/colinhacks/zod/issues/264 but here’s a bit of a snippet of the issue we’re trying to avoid:

Consider using this method on a transformer:

stringToNumber.transform(/* transformation_func */);

What type signature do you expect for transformation_func?

Most would probably expect (arg: number)=>number. Some would expect (arg: string)=>string. Neither of those are right; it’s (arg: number)=>string. The transformation function expects an input of number (the Output of stringToNumber) and a return type of number (the Input of stringToNumber). This type signature is a natural consequence of a series of logical design decisions, but the end result is dumb. Intuitively, you should be able to append .transform(val => val) to any schema. Unfortunately due to how transformers are implemented, that’s not always possible.

and

The fact that I incorrectly implemented both .transform and .default isn’t even the problem. The problem is that transformers make it difficult to write any generic functions on top of Zod (of which .transform and .default are two examples). Others have encountered similar issues. https://github.com/colinhacks/zod/issues/199 and https://github.com/colinhacks/zod/issues/213. are more complicated examples of how the current design of transformers makes it difficult to write any generic functions on top of Zod. Nested transformers in particular are a minefield.

Also consider this:

z.object({ type: z.literal("make me a string") }).transform(() => "i'm a string");

Obviously the object methods wouldn’t make sense here, but if you had a chain of different transform, you suddenly have to keep track of when they become object-like or array-like or promise-like or primitive-like, etc.

---

My personal recommendation is to separate out the input validation logic from any “effects” as a matter of principle when writing schemas. You can still just export the logical schemas most of the time, but in cases where you need to extend and apply effects to those schemas, either write a new schema in that same module, or export the base schema and effects to reassemble however you need.