You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I like how Zod has great auto-completion, but it currently results in unused code being loaded which increases bundle sizes (e.g. see #2596).
Module augmentation could be a great way to reduce the core Zod size and allow developers to optionally load additional schema methods. Zod can still be a large library. In fact, it can grow as much as wanted with lots of methods. Consumers will still only load what they want. Their bundle sizes will remain small and only grow as they opt-into more methods. This results in faster loading web pages, cloud function (e.g. AWS Lambda), etc.
This could be a breaking change or Zod could continue to export everything together but provide alternative import paths for this module augmentation leveraging approach.
Here is an oversimplified example that only loads desired methods:
import{z}from"./zod";import"./zod/string";import"./zod/string/max";console.log(z.string().max(12).parse("abc"));// => "abc"// cannot use .number() unless it is loaded by importing ./zod/number"// console.log(z.number().parse(42));// ^^^^^^ error TS2339: Property 'number' does not exist on type 'Zod'.
zod/index.ts
exportclassZod{}exportconstz=newZod();typeZodCheck<T>=(value: T)=>void;exportabstractclassZodSchema<T>{
#checks: ZodCheck<T>[];constructor(checks: ZodCheck<T>[]=[]){this.#checks =checks;}protectedabstracttypeCheck(value: unknown): asserts value is T;parse(value: unknown){this.typeCheck(value);for(constcheckofthis.#checks)check(value);returnvalue;}refinement(check: ZodCheck<T>): this {typeSelf= this;returnnew(this.constructoras{new(checks: ZodCheck<T>[]): Self})([
...this.#checks,check,]);}}
zod/number.ts
importtype{Zod}from".";import{z,ZodSchema}from".";exportclassZodNumberextendsZodSchema<number>{protectedtypeCheck(value: unknown): asserts value is number{if(typeofvalue==="number")return;thrownewError("value is not a number");}}declare module "."{interfaceZod{number(): ZodNumber;}}z.number=function(this: Zod){returnnewZodNumber();};
zod/string.ts
importtype{Zod}from".";import{z,ZodSchema}from".";exportclassZodStringextendsZodSchema<string>{protectedtypeCheck(value: unknown): asserts value is string{if(typeofvalue==="string")return;thrownewError("value is not a string");}}declare module "."{interfaceZod{string(): ZodString;}}z.string=function(this: Zod){returnnewZodString();};
I like how Zod has great auto-completion, but it currently results in unused code being loaded which increases bundle sizes (e.g. see #2596).
Module augmentation could be a great way to reduce the core Zod size and allow developers to optionally load additional schema methods. Zod can still be a large library. In fact, it can grow as much as wanted with lots of methods. Consumers will still only load what they want. Their bundle sizes will remain small and only grow as they opt-into more methods. This results in faster loading web pages, cloud function (e.g. AWS Lambda), etc.
This could be a breaking change or Zod could continue to export everything together but provide alternative import paths for this module augmentation leveraging approach.
Here is an oversimplified example that only loads desired methods:
zod/index.ts
zod/number.ts
zod/string.ts
zod/string/max.ts
The text was updated successfully, but these errors were encountered: