A "create a schema according to this type" helper

[rphlmr]

Hello,

What about adding a helper that takes a type and "forces" you to create a schema according to this type?

Can be useful, for example, to create a schema derived from a Prisma Model.

type Implements<Model> = {
  [key in keyof Model]-?: undefined extends Model[key]
    ? null extends Model[key]
      ? z.ZodNullableType<z.ZodOptionalType<z.ZodType<Model[key]>>>
      : z.ZodOptionalType<z.ZodType<Model[key]>>
    : null extends Model[key]
    ? z.ZodNullableType<z.ZodType<Model[key]>>
    : z.ZodType<Model[key]>;
};

export function implement<Model = never>() {
  return {
    with: <
      Schema extends Implements<Model> & {
        [unknownKey in Exclude<keyof Schema, keyof Model>]: never;
      }
    >(
      schema: Schema
    ) => z.object(schema),
  };
}

// usage
export type UserModel = {
  id: string
  email: string | null
  name: string
  firstName: string
  createdAt: Date
}

export const UserCreateSchema = implement<Omit<UserModel, "createdAt" | "id">>().with({
  email: z.string().email().nullable(),
  name: z.string(),
  firstName: z.string(),
});

export type UserCreatePayload = z.infer<typeof UserCreateSchema>

This is maybe not perfect, but I use this on my projects and I'm pretty happy with It.

Force to put nullable optional or nullish when Model requires it.
Unknown properties are forbidden and cause a TS error.

Discussed here : #372 (comment)

[DrJume]

Would love to have that! 👍

[EniacMlezi]

I tried using your example, but even putting the code in a sandbox like https://playcode.io/typescript gives me errors:

Somehow eventhough for instance 'name' is not Nullable or Optional, a ZodNullable<ZodOptional<ZodType>> definition is required in the schema. What's going wrong here?

[rphlmr]

You are wright, even on stackblitz!
Strangely, it works on VSCode 🧐

[EniacMlezi]

VSCode is where I first encountered the issue:

[EniacMlezi]

Saw this: #372 (comment),
EDIT Found it! I needed to set "strictNullChecks": true, in my tsconfig.json. thanks @rphlmr for this nice little tool!

But setting strictNullchecks in my tsconfig didn't do much for me. Might be that it is not using my tsconfig?

[rphlmr]

Ah yes I set it to true. Should edit my post 😅
Thx for the reminder.

[EniacMlezi]

Yeah that was it, all working now

[rogadev]

I have followed this through a chain of closed issues suggesting the feature of inferring a Zod schema from an existing type. There sure are quite a few closed issues requesting this feature. 🤔

Here's my take on why this should be included in Zod...

Say you have a prisma.schema that describes your data model.

enum VehicleType {
  SUV
  Van
  Compact
  Luxury
  Sedan
  Other
}

enum VehicleFuelType {
  Gasoline
  Diesel
  Electric
  Hybrid
  PluginHybrid
  Propane
  Hydrogen
  CNG
  Other
}

model Vehicle {
  id              Int        @id @default(autoincrement()) @map("vehicle_id") @unique
  created_by      String
  date_added      DateTime
  last_updated    DateTime
  name            String
  description     String?
  make            String
  model           String
  year            Int
  type            VehicleType
  fuel_type       VehicleFuelType
  departing_from  String

  @@map("vehicle")
}

Well, let's say I want to do some form validation. I have a "submit" form that captures and sends a POST request to my backend, and I can, of course, import this as a type into my project like so:

import type { Vehicle } from '@prisma/client'

But the thing is, I can't simply infer a Zod schema.

import type { Vehicle } from '@prisma/client'
import { z } from 'zod'
const vehicleSchema = z.inferSchema(Vehicle)

Which means instead of writing 3 elegant lines of code, if I want to reach for Zod to handle some client-side validation, I have to do some ugly garbage like this:

import { VehicleType, VehicleFuelType } from '@prisma/client'
const vehicleFormSchema = z.object({
  id: number(),
  date_added: z.date(),
  last_updated: z.date(),
  name: z.string(),
  description: z.string(),
  make: z.string(),
  model: z.string(),
  year: z.number(),
  type: z.nativeEnum(VehicleType),
  fuel_type: z.nativeEnum(VehicleFuelType),
  departing_from: z.string()
});
type VehicleForm = z.infer<typeof formSchema>;
// ... etc

All just to effectively re-declare a type that I already have already defined.

Now, yes, I get that using Zod is most valuable when you're writing custom error messages for each type of validation error/issue, and you could argue that you should do all Zod validation as above. But in my use case, I have no custom error messages in this validation, because maybe that's all I need. If I do want custom error messages from Zod, and I wanted to z.inferSchema() as I've suggested, perhaps there could be some sort of enhancement method to chain on that looks something like this:

const vehicleFormSchema = z.inferSchema(Vehicle).enhance({
  // ... custom fields & error messages go here
})

In my mind the above idea would give you some kind of hinting/feedback inside of enhance() that would ensure you didn't add fields that don't exist on your Vehicle type.

[Forsect]

Oh yes! @colinhacks we beg you for that!

[psychedelicious]

There are a few libraries that generate zod schemas from prisma types: https://zod.dev/?id=x-to-zod

IMO, it doesn't belong directly in zod. Zod itself should deal with native javascript types, not vendor types like prisma schemas.

Maybe an inferSchema API that accepts the external model and a transformer callback? But that doesn't really offer much that wouldn't already be served by use using any of the x-to-zod generators.

[enpitsuLin]

It is an inferred type that I used to resolve this question

export type Equals<X, Y> = (<T>() => T extends X ? 1 : 2) extends <T>() => T extends Y ? 1 : 2 ? true : false

type NonUndefined<T> = Exclude<T, undefined>

export type ZodInferSchema<T extends object> = {
  [Key in keyof T]-?: Equals<T[Key], NonUnderfined<T[Key]>> extends false
    ? z.ZodOptional<z.ZodType<NonNullable<T[Key]>>> | z.ZodPipeline<z.ZodOptional<z.ZodType<any>>, z.ZodType<T[Key]>>
    : z.ZodType<T[Key]> | z.ZodPipeline<z.ZodType<any>, z.ZodType<T[Key]>>
}

it works perfectly in my code with prisma

---

I updated my code that can work with .optional() now

[psychedelicious]

Great idea.

I've been using https://docs.tsafe.dev/equals in unit tests to ensure any manually created schemas match external types.