I am trying to use typescript types generated based on api/src/graphql/* for api and web because graphql sdl has been modified for better grapqhl schema usage after using yarn redwood generate scaffold.
The problem is generated prisma types i.e., Prisma.EmployeeUpdateInput was enough for typing graphql operations part under api and web at first but it is not anymore after modifying sdl. So, I tried to use transform tool for generating TypeScript types based on GraphQL Schema and put them under somewhere like web/src/@types/… But, it can’t be used for both api and web if it is under only one side.
Hey @sangheestyle, we keep “meeting” each other on typescript issues
So for your shared types we need to do a few things:
Put your shared types at the root of the project (makes sense right?), maybe in @types at the root
You can call this folder whatever you like ofcourse, just add the same folder to your includes
Modify your web/tsconfig.jsonandapi/tsconfig.json by adding this to your includes:
Which generator are you using @sangheestyle? I literally just started doing this with graphql-code-generator and I haven’t gotten to the issue you’ve describe yet, but great idea for getting shared types working properly.
Hey @brentjanderson - I was going to look into integrating this directly into Redwood. Shall we connect on discord if you have it working for your project already?
It’s not too complicated, but will require a change to the scaffolding tool to generate unique graphql operation names for every query/mutation. Presently, redwood generates duplicate query and mutation names in a few places (e.g. FooCell and EditFooCell will both have a query called FIND_FOO_BY_ID. If the scaffolder instead makes EditFooCell have a query called FIND_FOO_BY_ID_FOR_EDITor have EditFooCell import the query from FooCell then that solves that issue. There’s a similar issue for mutations.)
This has helped me squash a ton of bugs as my SDL drifts away from mirroring prisma and into what I need for my application, and the type safety in my service code has been a life saver.
While we’re on the topic of typescript, scenario always comes up as a missing type. I’ve done the following to fix that:
Add a root @types directory and add it to my tsconfig.json as described previously
Add the file @types/redwood-overrides.d.ts with the following contents:
import { defineScenario as __defineScenario } from '@redwoodjs/testing/dist/scenario'
type scenario = (title: string, callback?: (scenario: any) => void) => void
declare global {
const scenario: scenario
const defineScenario: typeof __defineScenario
}
I’m going to use this to add in extra types as needed. Eventually it would be nice to have better than any in my scenario, but this is working so far.
I prefer the generated types on the API side, but that’s mostly because my SDL and my Prisma schema are somewhat divergent. I can see the prisma types being a good starting point, but if my services are presented via GraphQL then whatever GraphQL takes as input/output is what my service methods need to comply to.
Redwood v0.33 now ships with almost complete TypeScript support. Please let us know of your dev experience after you upgrade, and remember to follow the release notes for manual codemods to get it all working!
The config for shared types now comes by default, as well as scenarios, gql query types, apollo client types. Thanks for your help on getting the ball rolling @brentjanderson and @sangheestyle!
We integrated rw v0.33 into our code and it worked really well. Really appreciate it and sorry for late response.
BTW, you asked me the following:
PS: Are you building anything cool? Would love to hear a bit more if you’re willing to share
Yes, we are building web app on web view for our mobile app product and it is almost done. I would love to share what we have done after release our product.
