chore(tests): setup zod type checking unify #627
Conversation
| @@ -0,0 +1,12 @@ | |||
| { | |||
There was a problem hiding this comment.
Any reason why this is needed? Seems the tests work without it
There was a problem hiding this comment.
Mainly because without this I would have difference between what's VSCode considered like an error and the result I would get when actually running the tests. With this being explicitly set, I get the same consistent result between the VSCode editor and the type-check results when running the tests with jest.
| parent_id: | ||
| | (number & { | ||
| description: string | null | ||
| id: number | ||
| parent_id: number | null | ||
| }) | ||
| | null |
There was a problem hiding this comment.
This was the kind of unwanted intersection that were created this number & {...}. It also cause all the "methods" of number to be available to the "results" (.toFixed, ...). This is now corrected by ensuring the result recursion won't use intersection but instead, always override the value by what's further down the recursion chain.
| type ExpectedType = Prettify< | ||
| Database['public']['Tables']['best_friends']['Row'] & { | ||
| first_user: string & Database['public']['Tables']['users']['Row'] | ||
| } | ||
| > |
There was a problem hiding this comment.
Invalid intersection now fixed.
| const ExpectedSchema = z.object({ | ||
| username: z.string(), | ||
| messages: z.array(z.object({ id: z.number() })), | ||
| user_profiles: z.array(z.object({ id: z.number() })), | ||
| }) | ||
| type ExpectedType = z.infer<typeof ExpectedSchema> | ||
| let result: Exclude<typeof res.data, null> | ||
| let expected: ExpectedType | ||
| expectType<TypeEqual<typeof result, typeof expected>>(true) | ||
| ExpectedSchema.parse(res.data) |
There was a problem hiding this comment.
Here is what the migration to zod looks like. The expectType remains, but now we also ensure the actual result match the expected result (at least pass zod validation).
This will make it easier to spot drift between runtime behaviour and type expectation that trying to visually match what's inside the toMatchSnapshot and the expectType definition.
* chore(tests): use zod schemas for both type assertions and rutime results validations * fix(types): self-reference relationship unwanted intersection * chore: context for tsconfig.test.json --------- Co-authored-by: Bobbie Soedirgo <[email protected]>
Fixes regression introduced in #627 While fixing the invalid intersection for conflicting keys case the Omit did lead to a huge increase in the recursive type complexity Removing it bring back the corner case, but allow much more longer queries. A test is now in place to ensure minimal coverage over the query complexities we can handle before reaching infinite recursion errors.
* fix(typegen): avoid possible infinite recursion error - Add a fixed max depth to recursive types allowing Typescript to not raise possible infinite recursion error too early. - Add test to ensure that the provided fix remove this error from a recursive embeding Related: supabase/supabase-js#1354 supabase/supabase-js#1372 supabase/supabase-js#808 * fix(typegen): infinite recursion error Fixes regression introduced in #627 While fixing the invalid intersection for conflicting keys case the Omit did lead to a huge increase in the recursive type complexity Removing it bring back the corner case, but allow much more longer queries. A test is now in place to ensure minimal coverage over the query complexities we can handle before reaching infinite recursion errors. * chore: add types test watcher * chore: watch over all src
|
🎉 This PR is included in version 1.21.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
What kind of change does this PR introduce?
Still in the idea to make a more straightforward, unified and strongly typed values for our tests:
Introduce
zodschemas and re-use the same schemas to both:Doing so, found a bug where self-referencing embeding via columns name would cause an unwanted intersection and fixed it.