Prisma Zod Generator

While the core Prisma Zod Generator emits Zod schemas, the Pro version provides 'Packs' that generate additional layers of code from the same Prisma schema. These packs include:

• Forms UX: Schema-driven React forms using Zod and React Hook Form (RHF).
• SDK Publisher: Typed TypeScript and Python HTTP clients.
• API Docs: OpenAPI specifications and a runnable mock server.
• Policies: PII redaction and policy helpers via annotations.
• Postgres RLS: PostgreSQL Row Level Security session context helpers.
• Multi-Tenant: Server-side tenant validation, middleware, and extensions.
• Performance: Streaming validators for large arrays.
• Factories: Realistic test data builders.
• Drift Guard: CI tools to detect breaking schema changes.
• Contracts: Consumer/provider test definitions.
• Server Actions: Typed actions validated with Zod.

It is important to distinguish between controlling Prisma's optionality and making entire variants partial:

• optionalFieldBehavior: Specifically controls how Prisma-defined optional fields (e.g., String?) are handled in pure model schemas.
• partial flag: A setting within variants that makes ALL fields in that variant optional, regardless of whether they were optional in the Prisma schema.

Example of combining both in zod-generator.config.json:

{
  "optionalFieldBehavior": "optional",
  "variants": {
    "input": {
      "enabled": true,
      "partial": true
    }
  }
}

The kit automatically detects tenant columns using common names like tenantId, organizationId, workspaceId, or companyId. If your schema uses a custom name (e.g., orgId or accountId), you must specify it using the tenantField key within the multiTenant JSON configuration in your schema.prisma generator block.

Requirement: This requires version 2.4.1+. In earlier versions, tenantField was ignored, and validateTenantAccess() would throw No tenant validator found for model: <Model> if the field name was unrecognized.

// Example of custom tenant field configuration
generator pzgPro {
  provider = "node ./node_modules/prisma-zod-generator/lib/cli/pzg-pro.js"
  output = "./generated/pro"
  enableMultiTenant = true
  multiTenant = "{ \"tenantField\": \"orgId\" }"
}

By default, the generator uses a multi-file layout. The structure is as follows:

• helpers/: Contains helpers for Json or Decimal fields.
• schemas/: The root for CRUD operation schemas (e.g., findManyUser.schema.ts).
• schemas/enums/: Generated enums.
• schemas/objects/: Generated object schemas.
• schemas/results/: Result schemas (enabled in full mode).
• schemas/variants/: Contains pure, input, and result variants.
• schemas/models/: Contains pure models (only present if pureModels: true).
• schemas/index.ts: A barrel file re-exporting all generated content.

Single-file mode: If you set useMultipleFiles: false, all schemas are collapsed into a single file (e.g., prisma/generated/schemas.ts).

To keep files clean, import type { Prisma } is only emitted if the file's typed export actually references Prisma.

Note on Decimal Mode: If decimalMode: "decimal" is configured, Prisma is imported as a value instead of a type, because the generator needs the runtime value for Prisma.Decimal.isDecimal checks and Decimal defaults.

Input object schemas (e.g., UserCreateInput.schema.ts) ignore the optionalFieldBehavior setting and follow a fixed policy to ensure compatibility with Prisma's API requirements:

• Optional non-relation fields (scalars, enums, unions): Emitted as .optional().nullable() to allow both omission and explicit null.
• Optional relation-shaped fields: Emitted as .optional() only. They reject null; you must omit the field to skip the relation.

Example of Object Schema behavior:

// Optional non-relation scalar
name: z.string().optional().nullable()

// Optional relation-shaped fields
author: z.lazy(() => UserCreateNestedOneWithoutPostsInputObjectSchema).optional() 
// ✅ undefined is ok
// ❌ null is invalid; use omission instead

In result schemas, relation fields are typed as z.array(...).optional() because relations only appear when explicitly included in a query.

• With pureModels enabled: The relation is typed against the related model's schema (e.g., z.array(TagSchema).optional()) via an import.
• Without pureModels (or for self-relations/single-file mode): The generator falls back to z.array(z.unknown()).optional() to prevent cyclic reference errors.

When the generator encounters a [TypeName] annotation, it attempts to resolve it to a Zod schema using the following priority order:

1. Explicit Map: If configured in typedJson.map[TypeName], it uses that exact expression.
2. Module Import: It looks for <TypeName>{schemaSuffix} (where schemaSuffix defaults to Schema) imported from the path defined in typedJson.schemaModule.
3. Fallback: If neither resolves, the field is left as its default type (e.g., Json) and a warning is recorded. This ensures compatibility with schemas intended only for PJTG.

It is important to distinguish between prisma-zod-generator (PZG) and prisma-json-types-generator (PJTG) to choose the right tool for your needs:

• prisma-json-types-generator (PJTG): Primarily used to type the Prisma Client itself by rewriting index.d.ts. It is a compile-time tool.
• prisma-zod-generator (PZG): An additive tool that generates Zod schemas for validation. It does not type the Prisma Client.

You do not need to switch from PJTG to use PZG; they serve different purposes (runtime validation vs. compile-time client typing).

The generator supports three distinct modes that control which models, variants, and operations are emitted. Choose a mode based on the balance you need between output richness and schema complexity.