-
-
Notifications
You must be signed in to change notification settings - Fork 142
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
zod validation (fixes #364) #367
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty scared by the deletion of the type tests. I wrote most of them for very specific use cases that my team/I have in production in multiple projects. Very likely many others have the same requirements. Is slonik no longer supporting those use cases?
|
||
const anyTypedQuery = await client.any(sql<Row>``); | ||
expectTypeOf(anyTypedQuery).toEqualTypeOf<readonly Row[]>(); | ||
const anyTyped = await client.any(sql.type(Row)``); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the old test should be deleted? Is slonik going to stop supporting sql<Row>`select 123`
?? I would have thought this is just a new feature and should have corresponding new type tests. Right now this PR deletes many many tests that ensure slonik's types are correct for end users (since test/dts.ts also got deleted entirely).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see a path for supporting both. They don't mix will.
What happens if someone does:
sql<{id: number}>.type(
z.object({
id: z.string()
})
)`select 123`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a risk - that isn't valid ts syntax. The generic on sql
is only when used as a function directly. sql.type
is another, independent, generic function which returns a non-generic function. I'm very sure of this, and still pretty concerned about abandoning the existing (and totally satisfactory!) form slonik has now. If you're not convinced, can I have a few days to come up with a pull request which proves this out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're not convinced, can I have a few days to come up with a pull request which proves this out?
Absolutely!
26003d3
to
20c5683
Compare
20c5683
to
1d2b679
Compare
1d2b679
to
aaaca65
Compare
Closing in favor of #369. |
No description provided.