Open michaelschufi opened 11 months ago
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.
@michaelschufi did you have any progress so far working on it ?
No. Unfortunately, I'm swamped atm. Also, so far I don't have any experience with writing such packages... 😅
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
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.
The point is you could define the strategy to use based on your preference and abstract some of the db design.
drizzle-orm
gives you.With the disadvantage of:
createInsertSchema
.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 :)
@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.
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?
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.
It seems like the current solution without codegen is a security concern.
.ts
schemacreateSelectSchema
generates basic Zod schema.pick()
and .extend()
.ts
schemaWhat are your thoughts? I guess the only solution as of now is to not use drizzle-zod
- at least on the client
Describe what you want
I love the idea of
createInsertSchema
andcreateSelectSchema
.However, extending the Zod schemas generated by those functions and importing them in a client component, results in
drizzle-zod
anddrizzle-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 generatez.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?