Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate zod schemas instead? #86

Open
rvdende opened this issue Jul 17, 2023 · 16 comments
Open

Generate zod schemas instead? #86

rvdende opened this issue Jul 17, 2023 · 16 comments
Labels
feature request New feature or request

Comments

@rvdende
Copy link

rvdende commented Jul 17, 2023

As the title says, who would be interested in generating zod schemas instead of typescript? What I see is often we have to manually create zod schemas for input validation before it gets passed to kysely, so if we could automatically keep our zod schemas in sync with the database that would be ideal!

Just curious if anyone else is looking into this?

Upvote & Fund

  • We're using Polar.sh so you can upvote and help fund this issue.
  • We receive the funding once the issue is completed & confirmed by you.
  • Thank you in advance for helping prioritize & fund our backlog.
Fund with Polar
@MuhammadAli-208
Copy link

it would be nice and will save lots of effort.

@elitan
Copy link
Contributor

elitan commented Jul 18, 2023

I just happened to find this repo: https://github.com/maktouch/kysely-zod-codegen

@rvdende
Copy link
Author

rvdende commented Jul 18, 2023

I just happened to find this repo: https://github.com/maktouch/kysely-zod-codegen

@elitan Oh wow this looks great thanks for the link. Would make sense to merge this upstream, perhaps with an option to toggle it on/off.

@drewbitt
Copy link

Is @maktouch interested in opening a PR? Great work!

@maktouch
Copy link

I'd like that! Wasn't sure if it would be accepted so I forked it cause I needed it right away.

There's a few downsides to it, it seems like I need to also generate using non-zod types for it to work correctly with kysely. It seems to work well for selects, but craps out for updates and inserts and I'm not too sure why.

@RobinBlomberg RobinBlomberg added the feature request New feature or request label Aug 8, 2023
@jjdonov
Copy link

jjdonov commented Aug 11, 2023

I was just looking for this exact thing and came across @maktouch 's fork before this thread. I'd love to see something similar land here (or to bring that solution upstream)

@maktouch do you have any examples or reproductions of those issues?


edit: @maktouch it looks like issues are closed on ur repo? but wanted to report that it looks like the code skips generating enums rn (is supported by kysely-codegen)

@maktouch
Copy link

@jjdonov hey, thanks for letting me know. I've enabled issues on the repo. I'll try to add reproduction for the non working inserts and updates.

@thelinuxlich
Copy link

Your solution should generate three shapes for each entity, insertable/updatable/selectable

@maktouch
Copy link

maktouch commented Oct 4, 2023

Yeah I think that's the issue --- I needed it pretty quickly so right now I generate both from kysely-codegen and kysely-zod-codegen. Shitty hack, and I hope to find time to actually generate the three shapes for each entity.

@a4vg
Copy link

a4vg commented Apr 30, 2024

Can I help with it? I'm building a CRUD API and a zod generated schema would be very helpful for validation.

@T04435
Copy link

T04435 commented May 17, 2024

I'd like that! Wasn't sure if it would be accepted so I forked it cause I needed it right away.

There's a few downsides to it, it seems like I need to also generate using non-zod types for it to work correctly with kysely. It seems to work well for selects, but craps out for updates and inserts and I'm not too sure why.

FYI I have been writing zod types for Kysely and I think with smt like this in the @maktouch generator PR it could be solved

import { Insertable, Selectable, Updateable, Kysely } from 'kysely';
import { z } from 'zod';

// have not test @maktouch gen but assume this is done from DB Schema
export const fooSchema = z.object({
  foo: z.string(),
});

// Then add this to generator
export type FooTable = z.infer<typeof fooSchema>;
export type Foo = Selectable<FooTable>;
export type FooCreate = Insertable<FooTable>;
export type FooUpdate = Updateable<FooTable>;

// use it here
export type DB = {
  foo: Foo;
};

export const db = new Kysely<DB>({
  //...
});

Happy to help, what needs to be done.

@maktouch @RobinBlomberg great work.

@maktouch
Copy link

I've been using my fork for almost a year now for founderpath.com

Works great. It generates a giant file though. It generates both the typescript one and the Zod ones, and they have the same name.

I'm shy to promote it because it's quite different, and I killed all the tests 😅

Please do feel free to take some logic from my fork to put it back here.

@T04435
Copy link

T04435 commented May 20, 2024

@RobinBlomberg and others.

I have a working(some test failing) version of @maktouch fork.

What would be an acceptable PR to land here.

Gen zod types based on a config flag OR always zod and TS types(no flag) ?

lmk 👍🏼

@maktouch
Copy link

imho, zod types should be behind a flag.

@RobinBlomberg
Copy link
Owner

To be honest, I'm reluctant to put Zod generation code directly into this codebase, adding more code to maintain and favoring it over Joi, Yup, Ajv, Valibot, JSON Schema and all other schema libraries people might use.

What I would like, however, would be one of these alternatives (probably both):

  1. Add a plugin system and allow people to add userland codegens. Ties into Add JSON configuration #34.
  2. Extract the database introspection CLI to a separate package (I've already completed most of the work on this) and let other packages depend on it, to easily create e.g. a Zod codegen.

I'll keep this issue up for a while for the sake of discussion, but I want to be clear that I won't add Zod directly into this repository, as I think other solutions would be better all around.

@maktouch
Copy link

that would be really dope and a way better solution than hardcoding. In my fork, I also needed another dialect (bigquery). It would be nice if the plugin can also handle that... I really would like to kill my fork lol

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
None yet
Development

No branches or pull requests

10 participants