[FEATURE]: Codegen for zod schemas

[michaelschufi]

Describe what you want

I love the idea of createInsertSchema and createSelectSchema.

However, extending the Zod schemas generated by those functions and importing them in a client component, results in drizzle-zod and drizzle-orm being in the client bundle. That's more than 20 KB gzipped, afaik. Also, TypeScript has a hard time inferring the whole tree back to the table definitions.

Because of that, I propose a codegen feature for drizzle-zod, which would generate z.object(...) code (what e.g. createInsertSchema would produce) in a different file. This way, it can be easily imported in the client and the performance should improve as well.

What do you think?

[dankochetov]

This sounds like a good idea overall, but a non-target for us for the moment. Feel free to implement it as a 3rd party package if you'd like, though! We'd be happy to highlight it in the docs as a community package.

[25khattab]

@michaelschufi did you have any progress so far working on it ?

[michaelschufi]

No. Unfortunately, I'm swamped atm.
Also, so far I don't have any experience with writing such packages... 😅

[michaelschufi]

Maybe it would make more sense to turn it around and use a different approach altogether. I.e. make a wrapper around drizzle's table definition function (e.g. pgTable) that consumes a Zod schema and returns the table schema.

I'm not sure yet, if this will work better. But

• It would allow you to use the Zod schema in a client without including drizzle-orm in the client bundle.
• You don't need to generate code, you can just define the schema once with Zod.
• You have a well defined way of handling certain structures, e.g. discriminated schemas or json fields.

  • E.g.: If you encounter a discriminated schema, you can always create the same strucutre you want.

    • Flattened approach in the same table? -> You can make the discriminator into an enum and the fields that are not shared nullable in the database.
    • Create two tables based on the schema and link it with FKs? -> Do that instead. (Is a "bit" 😅 bigger use case, but I can have a vision 😛)

    The point is you could define the strategy to use based on your preference and abstract some of the db design.

• You can still use all the types drizzle-orm gives you.

With the disadvantage of:

• You have to provide a way to adjust column configs - similar as drizzle-zod does it now by letting you override the Zod schema after it has been generated by e.g. createInsertSchema.
• Not having two different Zod schemas for insert/select.
  • I don't think it's that necessary, since drizzle itself has types for that.
• Maintaining it is harder, even for the simple cases, since drizzle is moving pretty fast 🚀 atm.

In general, I like the idea of thinking from the use-case point of view, rather than the database one. 99% of the time I need a new entity, I think about it's usage (with validation) first, before thinking about how the db should be designed. Also, I almost always need to enhance drizzle-zod's returned schemas.

What do you think?

P.S. I can also turn this into a discussion if that's a better place, just tell me :)

[swerky]

@michaelschufi I personally love this idea.

A complicate point that I see, will be to define some specific database type (ex: jsonB, enums etc.).

Just sharing my thoughts.

Have a good day.

[mooxl]

I'm currently facing this problem. I don't want to include the database schema in my client bundle. Is there a workaround available for using the generated zod schema in the client without including the database schema?

[LilyRose2798]

Also facing this problem. Have currently resorted to just defining the zod schemas manually and using TS to validate that it matches whatever the output of createSelectSchema would be using const myTableSchema = z.object({ ... }) satisfies z.ZodObject<BuildSelectSchema<typeof myTable, {}>> but it would be really nice to have a better solution for this.

[stabildev]

It seems like the current solution without codegen is a security concern.

• Define Drizzle .ts schema
• createSelectSchema generates basic Zod schema
• Define endpoint validators from generated Zod schema using .pick() and .extend()
• Import the validator on the client for client-side (pre-)validation
• Result: db schema leaked to the client, as the validator is just a function that calls the generator that calls the .ts schema

What are your thoughts? I guess the only solution as of now is to not use drizzle-zod - at least on the client

[gregegan]

Any progress on this feature? Feels essential to implement this