The schema (`backend/src/schema.graphql`) is the contract between the backend and the frontend, but the resolvers and the queries in the frontend are typed by hand, so they can drift from it without anything failing. [GraphQL Code Generator](https://the-guild.dev/graphql/codegen) makes TypeScript types from the schema, so a change in the schema shows up as a type error. ## Scope - **Tool.** `@graphql-codegen/cli` with the `typescript` and `typescript-resolvers` plugins for the backend. The config is `codegen.ts` in `backend/`, with the schema file as input and `backend/src/generated/graphql.ts` as output (the folder is already ignored for Prisma, check that this file is ignored or committed in the same way). Scalars (`ID`, `DateTime`) and the context type (`Context`) are mapped. - **Backend use.** The resolvers use the generated `Resolvers` type, so a resolver with wrong arguments or a wrong return type fails `tsc`. Start with the catalog and user data resolvers that exist. Mappers where a resolver returns a Prisma row and not the GraphQL type (for example `CatalogEntry` for search results, `Coach`). - **Script.** `npm run codegen` (root and `backend`). `lint`, `build` and the tests run it first, or CI fails if the generated file is out of date: decide which, and write it in the README. - **Frontend (later, with Apollo Client).** The same schema can make typed documents for the frontend. Out of scope here, but the config should not make it harder. - **Prettier.** `schema.graphql` is formatted with Prettier; the generated file is ignored by Prettier and ESLint. ## Done when - [ ] `npm run codegen` makes the types from `schema.graphql` without errors - [ ] The existing resolvers are typed with the generated `Resolvers`, and `tsc`, lint and the tests pass - [ ] Changing a field in the schema without changing its resolver makes `tsc` fail (shown in the PR) - [ ] The README says how and when to run it - [ ] `docs/API.md` "Tools" is up to date Depends on the GraphQL server (#28).