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

Feature request/question: Support for generating Zod validator objects when doing type inference #295

Open
adevine opened this issue Dec 3, 2024 · 7 comments

Comments

@adevine
Copy link

adevine commented Dec 3, 2024

Hello! I just wanted to say this is a truly awesome project! I haven't played with it much yet but reading through the docs it seems like the perfect compliment and the one "missing piece" to my favorite SQL library, Slonik.

My question/feature request:

Slonik lets you do runtime-type validation using Zod validators. Seeing as how this library can generate the Typescript definitions in a sql<{ ... }> tag, it seems then it would also be possible to have similar code that generates a Zod validator that could be used in a sql.type(...generated Zod object goes here...) tag. I love using Zod validators with Slonik, the one downside is that they can be time-consuming/tedious to write manually, but looking through this library it seems like all of the underlying type-analysis pieces are here that would make in relatively straightforward to create a Zod object instead of a TypeScript type.

I wasn't sure if this question belongs better here or on the Slonik project, but I saw @gajus posted some issues here so thought maybe he could give his thoughts on whether this is a good idea. I didn't want to think of this as a formal feature request yet, just interested if you thought this was a workable idea to begin with.

Again, thanks for a fantastic project!

@karlhorky
Copy link
Collaborator

@adevine I'm not sure I understand the proposal, maybe you can edit the description above to be more clear and include 1 or 2 code examples?

As far as I understand, SafeQL doesn't have runtime behavior currently - it is an ESLint plugin.

@gajus
Copy link
Contributor

gajus commented Dec 4, 2024

I think they are asking for the ability to generate zod types based on the query, e.g.

SELECT id, name
FROM person

Would need to become:

const personQuery = sql.type(
  z.object({
    id: z.number(),
    name: z.string(),
  })
)`
  SELECT id, name
  FROM person
`;

@karlhorky
Copy link
Collaborator

Maybe during ESLint autofix, is that what you mean?

That could be possible I guess... Although sounds like it could get complicated

@gajus
Copy link
Contributor

gajus commented Dec 4, 2024

Maybe during ESLint autofix, is that what you mean?

That could be possible I guess... Although sounds like it could get complicated

Indeed.

It should involve about the same level of complexity there is today with type generation.

Personally, I quite enjoy writing zod types myself, but I've definitely had people ask for some relief with this process, so this would be a welcome addition.

@karlhorky
Copy link
Collaborator

karlhorky commented Dec 4, 2024

Any kind of code / schema generation is great in my book, yeah 🙌 So purely from the feature perspective, totally can support this.

But I'm not sure if this fits the project SafeQL, or if SafeQL only wants to deal with TypeScript types on their own.

One additional wrinkle to the implementation is that sql.type() method needs to be implemented in all sql tagged template literal libraries who want support of this - eg. this would fail out of the box with Postgres.js

@gajus
Copy link
Contributor

gajus commented Dec 4, 2024

Yeah, I expect this to be pretty specific to Slonik. As far as I am aware, no one caught up with Slonik in this regard.

@gajus
Copy link
Contributor

gajus commented Dec 4, 2024

However, @Newbie012 mentioned that you are moving in a direction of developing driver specific implementations, so it would seem appropriate for that logic to live there.

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

No branches or pull requests

3 participants