Zod resolved type change for Opaque type between v3.14.4 -> v3.15.1

[bluepnume]

I have the following code:

type Opaque<Type, Token = unknown> = Type & { tag: Token }; 

enum FACE {
    QUEEN = 'QUEEN',
    KING = 'KING'
}

enum SUIT {
    HEARTS = 'HEARTS',
    DIAMONDS = 'DIAMONDS'
}

type FaceCard<Face extends FACE> = Opaque<`${ Face }_${ SUIT }`, 'FaceCard'>;

type Hand = z.output<
    z.ZodObject<{
        card : z.ZodType<FaceCard<FACE.QUEEN>, z.ZodTypeDef, string>,
    }>
>;

In zod@3.14.4, Hand resolved to:

type Hand = {
    card: FaceCard<FACE.QUEEN>;
}

But now in zoid@3.15.1, Hand is resolving to:

type Hand = {
    card: (FaceCard<FACE.QUEEN> | undefined) & FaceCard<FACE.QUEEN>;
}

Why did the second type get more complex here, when the first one is correct?

(By the way -- incredible library. Thank you for making this, seriously.)

[bentefay]

Hi @bluepnume.

Sorry about this. I changed the definition of z.ZodObject in my PR (#1117) that was recently merged. Its behaviour was unchanged in all the cases I tested, but it looks like you found a case that resolves differently. I've made a PR that fixes the type to preserve the existing behaviour for your example (#1122).

As a side node, although the type looks ugly and we should definitely fix the problem, I believe the types { property: (T | undefined) & T } and { property: T } are technically the same, so hopefully you shouldn't be seeing any issues with using the type until my PR is merged. Is that right?

[bluepnume]

Thanks @bentefay! Appreciate the fast turnaround!

No huge rush to merge, since I can just lock to 3.14.4 for now. But since you asked, the issue that this causes for me is demonstrated with the following code:

type QueenCard = Hand['card'];

type CardValue = {
    [ FACE.QUEEN ] : 12,
    [ FACE.KING ] : 13,
};

type CardToValue<Face extends FACE> = Face extends keyof CardValue
    ? CardValue[Face]
    : never;

const cardToValue = <Face extends FACE>(card : FaceCard<Face>) : CardToValue<Face> => {
    return someLogic(card);
};

const value = cardToValue('' as QueenCard);

const expectedValue : 12 = value;

console.log('Value is', value, 'expected', expectedValue);

^ This code type-checks with 3.14.4. But with 3.15.1, I get:

const expectedValue : 12 = value;

Type '12 | 13' is not assignable to type '12'.

-- essentially, while (T | undefined) & T and T are equivalent, you can use T as an index but you can't with (T | undefined) & T, so this type refinement breaks other parts of my code that rely on that.

[bentefay]

Ahh that makes complete sense. It's also not something I could have possibly dreamed up as a test 😄. Now I see it though I suppose we could add that as a unit test, though it would be perhaps a little too specific? I wonder if there is a simpler set of types that expose the problem.

[colinhacks]

Resolved in 3.16, thanks @bentefay

[bluepnume]

Thanks @bentefay and @colinhacks! And again thanks for a stellar library, you guys rock.