Generates Zod schemas for the specified Typesync schema and writes them to the specified file. The generator can produce code for either Zod v3 or v4, and can optionally emit inferred TypeScript types alongside the schemas.Documentation Index
Fetch the complete documentation index at: https://docs.typesync.org/llms.txt
Use this file to discover all available pages before exploring further.
Usage
Options
The exact path or a Glob pattern to the definition file or files. Each definition file must be a YAML or JSON file containing model definitions.
- Example single file path:
definition/models.json - Example Glob pattern:
'definition/**/*.yml'
The target environment for which the types are generated. This option specifies the target SDK and version, ensuring
that the output is compatible with the chosen environment. See the list of available targets here.
The path to the output file.
Which Zod major release the generated code should target. Pick the variant that matches the
zod version installed in
the consuming project. The two majors differ in a couple of API surface points (the z.record key argument and the
strict / loose object factories) and the generator emits the right shape for each.The pattern that controls how the generated Zod schema constants are named. The pattern must be a string that contains
the
"{modelName}" substring (this is a literal value).Example values:"{modelName}Schema"→ produces exports likeUserSchema,PostSchema,AccountSchemaetc."z{modelName}"→ produces exports likezUser,zPost,zAccountetc.
When enabled, the generator emits an inferred TypeScript type alongside each Zod schema. For a model named
User with
the default patterns, the output becomes:The pattern that controls how the inferred TypeScript types are named when
--emitInferredTypes is set. The pattern
must contain the literal substring "{modelName}". Ignored when --emitInferredTypes is not set.Example values:"{modelName}"→ produces types likeUser,Post,Accountetc."{modelName}Type"→ produces types likeUserType,PostType,AccountTypeetc."I{modelName}"→ produces types likeIUser,IPost,IAccountetc.
Indentation or tab width for the generated code.
Whether to enable debug logs.
Targets
generate-zod reuses the generate-ts target list. The --target option determines the runtime classes that the
generated z.instanceof(...) checks resolve to — pick the target that matches the Firestore SDK you decode documents
with.
firebase-admin@13: For backend projects that use Firebase Admin Node.js SDK (v13).firebase-admin@12: For backend projects that use Firebase Admin Node.js SDK (v12).firebase-admin@11: For backend projects that use Firebase Admin Node.js SDK (v11).firebase-admin@10: For backend projects that use Firebase Admin Node.js SDK (v10).firebase@11: For frontend projects that use Firebase Javascript SDK (v11).firebase@10: For frontend projects that use Firebase Javascript SDK (v10).firebase@9: For frontend projects that use Firebase Javascript SDK (v9).react-native-firebase@21: For React Native projects that use React Native Firebase (v21).react-native-firebase@20: For React Native projects that use React Native Firebase (v20).react-native-firebase@19: For React Native projects that use React Native Firebase (v19).
Notes
- References between models are emitted as
z.lazy(() => OtherSchema). Usingz.lazydefers identifier resolution until validation time, which keeps mutually recursive schemas working regardless of declaration order in the generated file. - Strict / loose objects map to
z.strictObject/z.looseObjectfor v4 and toz.object(...).strict()/z.object(...).passthrough()for v3. Whether an object accepts additional fields is controlled by theadditionalFieldsflag in the schema definition. - The Firestore SDK is only imported when at least one model uses
timestamporbytes. For the admin targets,bytesresolves to the Node globalBufferand does not trigger an SDK import on its own.

