I'm assuming you're using Apollo. This can be changed
-
Install a few dependencies:
yarn add -WD @graphql-codegen/cli @graphql-codegen/typescript @graphql-codegen/typescript-operations @graphql-codegen/typescript-react-apollo @graphql-codegen/typescript-resolvers npm-run-all ts-node -
In my setup, I also threw in
npm-run-alland made some edits to my root package.json "scripts":yarn add -WD npm-run-all"dev": "npm-run-all --parallel dev:**", "dev:rw": "rw dev", "dev:graphql-codegen:watch": "sleep 10 && graphql-codegen --watch ", // Sleep 10 so that redwood has ample time to boot up before we start generating types. Tune to your liking. // If graphql-codegen can hook into redwood's lifecycles then the sleep 10 would not be required
If you don't use npm-run-all, you will need to manually run
yarn graphql-codegen --watchafter startingyarn rw devin a separate console. -
Add
codegen.ymlverbatim to your project -
Anytime you scaffold new code, graphql-codegen will complain because the default redwood scaffold templates generate duplicate operation names.
e.g. if you have a model
Fooand you scaffold your frontend, you will getFooCellandEditFooCellwith the same query namedFIND_FOO_BY_ID.A quick fix is to either:
- Rename one query (I change the one in
EditFooCellto beFIND_FOO_BY_ID_FOR_EDIT) - Delete one and import it from the other instead.
In any case, the errors generated by graphql-codegen tend to be helpful in pointing out where the issue is and how to correct it. I haven't had issues apart from duplicate query/mutation names generated from scaffolding.
- Rename one query (I change the one in
I have not used this approach in production yet, so it may be desirable to create a root @types directory and have the generated files go there.