Martinsos
commented
2 months ago The main idea currently is, from what I got, to do "snapshot" testing of our typed API. We would in some way take a snapshot of our public facing types and compare that with any changes, to make sure we didn't by accident change what our types look like.
Potentially there are also some other ways to test types, like doing some assertions as @infomiho mentioned above, e.g. with @ts-expect-error.
sodic
We support Typescript and full-stack type safety is one of the best parts of Wasp. This means that how the user sees Typescript types and how they work is very important.
We can accidentally break the types user sees (e.g. some dependency (Prisma) updates their types, we update the way we structure our code (SDK and exports)). Most of the time we catch these regression since we also write Wasp apps and we test manually all of our examples before releases.
But, sometimes, we don't catch these regression due to TS server caching some results or similar.
Proposal
We need to introduce automated tests for the types the users see. Something that will take a generated Wasp app and ensure that the types for various Wasp features didn't break (operations on the server and client, various SDK helper functions etc. - what ever we feel that might break if we don't cover it with tests)
Some ideas on how to tackle it
Maybe we reuse our existing e2e tests pipeline and somehow include the Typescript compiler output for certain test files e.g. AST or inferred types in a format that can be diffed and we can catch regressions.
Or we write tests with
@ts-expect-error: https://betterprogramming.pub/getting-started-testing-types-in-typescript-f64306ec16bFor the time being, we've implemented some tests as a part of our internal todoApp: https://github.com/wasp-lang/wasp/pull/1992#discussion_r1579462879