Using typescript types after modifying api/src/graphql/*.sdl.ts


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.

Any help?

p.s., I used transformer Transform | A polyglot web converter

Hey @sangheestyle, we keep “meeting” each other on typescript issues :smiley:

So for your shared types we need to do a few things:

  1. 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
  2. Modify your web/tsconfig.json and api/tsconfig.json by adding this to your includes:
"include": [
  1. Restart TS server in vscode. And your new types should now be available on both web and api sides!

Hope this solves your problem!

PS: Are you building anything cool? Would love to hear a bit more if you’re willing to share

1 Like

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?

1 Like

Here’s a gist detailing my setup: Running graphql-codegen on Redwood · GitHub

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_EDIT or 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.

1 Like

While we’re on the topic of typescript, scenario always comes up as a missing type. I’ve done the following to fix that:

  1. Add a root @types directory and add it to my tsconfig.json as described previously
  2. 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.

Hey @danny @brentjanderson !

I am very busy these days so can’t follow up those great answers yet. I will be back soon!

1 Like

Question for you @brentjanderson - do you use the generated types on the API side or are the Prisma types sufficient?

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.

Thanks - could you share an example please? I’m looking to get this in for the next release just trying to work out the best experience