3.20: Input type of a schema with a coercion

[RobinTail]

I believe there is a confusion with the way how the new coerce feature works together with the inferring of the input type.

Here is the example with the ZodString having coerce enabled:

const schema = z.coerce.string(); // ZodString
console.log(schema.parse(123)); // "123", no errors
type SchemaInput = z.input<typeof schema>; // string
const input: SchemaInput = 123; // TS2322: Type 'number' is not assignable to type 'string'.

Under the hood, as per my understanding, the schema actually accepts any type of the input, making a String out of them.
However, inferring the input type of such schema returns string, so the coerce feature is not taken in account on the typescript level.

I believe, the z.coerce.string() should create ZodType<string, ZodStringDef, any> (input type — any, not equal to the output type — string).

what do you think, @colinhacks ?

[JacobWeisenburger]

I have confirmed this bug. Not exactly sure how to fix it though. Any ideas?

[RobinTail]

Not exactly sure how to fix it though. Any ideas?

Well... in order to preserve the backward compatibility, the following idea comes to my mind.
I'm going to explain it on the example of ZodNumber, however it could be applied to any class currently having coerce feature.

Consider the current declaration:

class ZodNumber extends ZodType<number, ZodNumberDef> { }
// input type is equal to the output one by default (number)

where coerce is the property within ZodNumberDef:

interface ZodNumberDef extends ZodTypeDef {
  checks: ZodNumberCheck[];
  typeName: ZodFirstPartyTypeKind.ZodNumber;
  coerce: boolean;
}

We need to make coerce to be a type argument with a backward compatible default. Here is the possible solution:

interface ZodNumberDef<Coerce extends boolean = false> extends ZodTypeDef {
  checks: ZodNumberCheck[];
  typeName: ZodFirstPartyTypeKind.ZodNumber;
  coerce: Coerce;
}

class ZodNumber<Coerce extends boolean = false>
  extends ZodType<
    number,     // output type
    ZodNumberDef<Coerce>,
    Coerce extends true ? any : number     // conditional input type
  > { }

It's only the beginning, for demonstrating a possible way of fixing this.
Additional corresponding changes would be required to align other statements that create the class instances.

@JacobWeisenburger

[RobinTail]

@JacobWeisenburger , I made a fix #1793 — please review.

[aleclarson]

I rewrote @RobinTail's fix to not be a breaking change by introducing new coerced types (eg: ZodCoercedString) and updating the z.coerce type signatures accordingly.

aleclarson@35e228f

The z.input results are aligned with each type's coercion expression. For example, doing z.input<ZodCoercedBigInt> will resolve to string | number | bigint | boolean, since that's what the BigInt constructor accepts (according to its TypeScript definition).

@colinhacks @RobinTail @JacobWeisenburger Does this sound like an acceptable solution?

edit: Well, I guess one could argue it's still a breaking change, since z.input results might be relied upon in application code. 😔 Oh, btw, I haven't done the Deno changes yet.

[maxArturo]

@aleclarson I took a quick look and having types with the actual expected coercion inputs seems reasonable to me, FWIW. It forces users to be explicit about disregarding the expected input types for those that need it (bigint and date maybe).

I'm not sure what would happen in re: to the coercion types sometimes not being assignable back to the zod "main" types, since I haven't worked in userland code that does that extensively. That would be a concern I think.

[RobinTail]

I rewrote @RobinTail's fix
aleclarson@35e228f

@colinhacks @RobinTail @JacobWeisenburger Does this sound like an acceptable solution?

Didn't you forget to cover the case like z.number({coerce: true})

@aleclarson

[aleclarson]

@RobinTail ah yes, I did 😞

[RobinTail]

That's why I went with the approach in my PR. I believe it's backward compatible while having defaults where type params are introduced.
However, if you have a better idea on how to achieve fixing this issue, I'd be happy if it would be fixed by any means, @aleclarson

[colinhacks]

This was a tradeoff with adding the coercion logic directly into the respective primitive schema types (ZodString, etc.). I could have introduced a ZodCoerce type that could properly represent the Input type, but then the various ZodString methods wouldn't have been available on z.coerce.string().

I don't like the idea of adding any generics to ZodString I'm afraid - it clutters up the Intellisense and I consider it a decent-sized hit to DX for all users to accommodate a rather niche problem. If you absolutely need proper input typing, you can still use the old approach:

const r = z.any().transform((val) => String(val));
type In = z.input<typeof r>;
type Out = z.output<typeof r>;

[aleclarson]

I don't like the idea of adding any generics to ZodString I'm afraid

Perhaps my approach is a good compromise then? …even though {coerce: true} is not supported, it enables the correct types when using the z.coerce API.

[colinhacks]

That seems messy to me and not worth the headache with assignability and whatnot. I was aware of this issue before selecting the current approach and I still think its the best option from a set of imperfect options. The true solution is to rewrite Zod to avoid classes/inheritance but in the meantime, this is the best tradeoff. I'm gonna close, thanks to everyone for the ideas and discussion.

[aleclarson]

That seems messy to me and not worth the headache with assignability and whatnot.

1. I don't know what you mean by "messy". Can you elaborate?

2. As for the assignability, what are the practical use cases where that becomes an issue.

3. Also worth bearing in mind that we can use any as the Input type in all cases if the assignability concerns are a deal breaker.

[RobinTail]

The true solution is to rewrite Zod

Then why do you close the issue? @colinhacks

It is a confirmed bug that remains, right?
Your vision is a refactoring, not a patch. Ok.
Do you have a plan for that in a some upcoming future? Should this plan refer to this issue?
I don't understand.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.