David Alonso•5mo ago

Using migration helpers `pretend` and `deprecated` with a zod schema

I'm defining my types primarily in zod and using zodToConvex I'm missing the equivalent of zid for the pretend and deprecated validators

6 Replies

ian•5mo ago

Gotcha - yeah the extracted types from zod are harder to cast. You could always override those fields though:

defineTable({
  ...zodToConvex(myZodObject),
  somefield: deprecated,
  otherfield: pretend(v.string()),
});

defineTable({
  ...zodToConvex(myZodObject),
  somefield: deprecated,
  otherfield: pretend(v.string()),
});

David AlonsoOP•4mo ago

ah nice, didn't think about that! Hey Ian, this solution gets a lot trickier to implement when the field is nested in some union type - any ideas on how to tackle that case or how hard it would be to create a zDeprecated operator?

ian•4mo ago

the deprecated type is just any cast to null so could you get away with const zDeprecated = z.unknown() and use that?

David AlonsoOP•4mo ago

When you say "harder", how hard are you talking about? We're currently defining part of our schema with zod to take advantage of defaults and reusability with other frameworks but we have to switch to validators only cause I have no idea how to do something like this with Zod:

export const vPretendNullWithConstraint = <C extends GenericValidator>(
  constraint: C
): Validator<null, "optional"> =>
  constraint as unknown as Validator<null, "optional">;


export const vPretendNullWithOptionalConstraint = <C extends GenericValidator>(
  constraint: C
): Validator<null, "optional"> =>
  v.optional(constraint) as unknown as Validator<null, "optional">;

export const vPretendNullWithConstraint = <C extends GenericValidator>(
  constraint: C
): Validator<null, "optional"> =>
  constraint as unknown as Validator<null, "optional">;


export const vPretendNullWithOptionalConstraint = <C extends GenericValidator>(
  constraint: C
): Validator<null, "optional"> =>
  v.optional(constraint) as unknown as Validator<null, "optional">;

Would be extremely beneficial for us to have these helpers in Zod, or #default() on Convex validators (which i think might be harder) if you need me to expand more on our use case and why this is so important to us I'm happy to do so

ian•4mo ago

I think this is a pure-zod question, right? You want one zod validator to pretend to be another - e.g. something like

export const zPretendNullWithConstraint = (
  constraint: ZodTypeAny<any>
): ZodNull =>
  return constraint as unknown as ZodNull;

export const zPretendNullWithConstraint = (
  constraint: ZodTypeAny<any>
): ZodNull =>
  return constraint as unknown as ZodNull;

You want the underlying zod type to carry through (and become that validator in Convex) but be treated like z.null()?

David AlonsoOP•4mo ago

yes exactly, and that when I do zodType.parse(value) it validates against the constraint It is a pure-zod question, I still really really appreciate the help. Will give this a try Does this look good?

export const zPretendNullWithOptionalConstraint = (
  constraint: ZodTypeAny
): ZodNull => {
  return constraint.optional() as unknown as ZodNull;
};

export const zPretendNullWithOptionalConstraint = (
  constraint: ZodTypeAny
): ZodNull => {
  return constraint.optional() as unknown as ZodNull;
};

Using migration helpers `pretend` and `deprecated` with a zod schema

Did you find this page helpful?