Record types should be partial

I love that in v3.9 we can now specify the type of the record key using enums or literals.

But the inferred Record type now needs to be wrapped in Partial, otherwise typescript forces us to specify every key, which is inconsistent with how the Zod parser interprets the same schema.

For example, suppose we create a schema that allows us to map states to temperatures:

const Weather = z.object({
    temperatures: z.record(z.enum(['VT', 'NH', 'CA', 'AZ']), z.enum(['warm', 'cold']))
});

If we map a couple of states, it parses fine. This parses without throwing:

Weather.parse({ temperatures: {VT: 'cold', CA: 'warm'} });

But if we try to use the inferred type with the same object, typescript is not happy:

type Weather = z.infer<typeof Weather>;
const weather: Weather = { temperatures: {VT: 'cold', CA: 'warm'} };

This gives us this error:

Type '{ VT: "cold"; CA: "warm"; }' is missing the following properties from type
'Record<"VT" | "NH" | "CA" | "AZ", "warm" | "cold">': NH, AZ
types.d.ts(639, 124)

It wants us to specify all the states in the enum, which is not intuitive or useful, and is inconsistent with the Zod parser.

[jeremybull]

@scotttrinh @colinhacks One option might be to accept and document the breaking change as a bug fix for the inconsistency (enum record keys have only been available since 3.9 and are not yet well documented, so won’t be widely adopted). Then we could add a partial() method to the record schema so anyone like me who wants the old parsing behavior can still get it.

[scotttrinh]

@jeremybull

Ahh, I see what you mean, I missed that part of the issue in my first read. Yeah, we should align the runtime and compile time behavior, I think. @colinhacks this feels like a breaking change since it causes schemas to fail that previously succeeded. Any thoughts or suggestions about what to do here?