Migrating to zod 3 - ZodType(?) issue
See original GitHub issueWe’ve been using zod 2 with great success, but now I’m having an issue migrating to zod 3. Here’s the piece of code representing the error:
import * as zod from 'zod';
const schema = zod.object({
videoDate: zod.string(),
});
class Editor<
S extends zod.ZodType<zod.TypeOf<typeof schema>> = typeof schema,
> {
constructor(public schema: S) {}
}
const advancedSchema = zod.intersection(schema,
zod.object({
videoDuration: zod.number(),
})
.refine(val => val.videoDuration > 5),
);
export class AdvancedEditor extends Editor<typeof advancedSchema> { // the error pops here
constructor(schema: typeof advancedSchema) {
super(schema);
}
}
This was legitimate in zod 2 , but turned out to be prohibited in zod 3 yielding the following error:
Type 'ZodIntersection<ZodObject<{ videoDate: ZodString; }, "strip", ZodTypeAny, { videoDate?: string; }, { videoDate?: string; }>, ZodEffects<ZodObject<{ videoDuration: ZodNumber; }, "strip", ZodTypeAny, { ...; }, { ...; }>, { ...; }>>' does not satisfy the constraint 'ZodType<{ videoDate?: string; }, ZodTypeDef, { videoDate?: string; }>'.
The types returned by '_parse(...)' are incompatible between these types.
Type 'ParseReturnType<ZodObject<{ videoDate: ZodString; }, "strip", ZodTypeAny, { videoDate?: string; }, { videoDate?: string; }> & ZodEffects<ZodObject<{ videoDuration: ZodNumber; }, "strip", ZodTypeAny, { ...; }, { ...; }>, { ...; }>>' is not assignable to type 'ParseReturnType<{ videoDate?: string; }>'.
Type 'OK<ZodObject<{ videoDate: ZodString; }, "strip", ZodTypeAny, { videoDate?: string; }, { videoDate?: string; }> & ZodEffects<ZodObject<{ videoDuration: ZodNumber; }, "strip", ZodTypeAny, { ...; }, { ...; }>, { ...; }>>' is not assignable to type 'ParseReturnType<{ videoDate?: string; }>'.
Type 'OK<ZodObject<{ videoDate: ZodString; }, "strip", ZodTypeAny, { videoDate?: string; }, { videoDate?: string; }> & ZodEffects<ZodObject<{ videoDuration: ZodNumber; }, "strip", ZodTypeAny, { ...; }, { ...; }>, { ...; }>>' is not assignable to type 'OK<{ videoDate?: string; }>'.
Type 'ZodObject<{ videoDate: ZodString; }, "strip", ZodTypeAny, { videoDate?: string; }, { videoDate?: string; }> & ZodEffects<ZodObject<{ videoDuration: ZodNumber; }, "strip", ZodTypeAny, { ...; }, { ...; }>, { ...; }>' has no properties in common with type '{ videoDate?: string; }'.ts(2344)
Can I follow the same approach now?
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
zod/MIGRATION.md at master · colinhacks/zod - GitHub
This is a migration guide to walk you through the process of upgrading to Zod 3. If you're upgrading directly from Zod 1,...
Read more >zod - npm
Use the or method to ZodType (the base class for all Zod schemas) to easily create union types like z.string().or(z.number()) ...
Read more >zod (or toZod): how to model "type" field in discriminated union
I think the quickest way to get this working is with ZodType : import { z } from "zod"; export interface ConnectorForModel {...
Read more >Supercharge your app with runtime type-checking using ZOD
Feb 12, 2022 • 3 min read ... ZOD can solve these issues, as it offers type-safety checks at runtime, take note that...
Read more >Zod | Documentation
Zod is a TypeScript-first schema declaration and validation library. ... During the parsing step, the input is passed through the String() function, ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@azhiv This actually was a bug… Fixed in
zod@3.8.2
The return type of ZodIntersection._parse was wrong. This must have been changed in the parser rewrite and no one caught it. Intersections aren’t very commonly used. But I agree with Scott that refinements should exist at the top-level if possible (though this is a stylistic preference and it should work fine your way).
Thank you!