GraphQL Code Generator: typed clients from a schema and your operations

The problem GraphQL Code Generator solves for schema-first teams

A GraphQL schema describes types, fields and arguments, but it says nothing about the language you write your client or server in. Without generation, every query result, every variable object and every resolver argument is typed by hand, and the compiler cannot tell you when a field was renamed or an argument became required. GraphQL Code Generator reads the schema and the GraphQL documents (queries, mutations, subscriptions, fragments) and emits source files in the target language. The README states the tool "generates code out of your GraphQL schema" and that it works "whether you are developing a frontend or backend". The audience is therefore anyone with a schema and a typed codebase: TypeScript and React frontends, Angular and Vue applications, resolver layers, and the Java, C#, Python and other targets the plugin list covers. The project's own description names the mechanism plainly: flexible support for custom plugins.

How the CLI, plugins and presets fit together

The architecture is a pipeline with three moving parts. The CLI loads a schema (from a URL, a local file or a running server), loads the operations, and parses both into an internal document model. Plugins then consume that model and return strings. Presets decide where those strings go and how files are split. Output format is therefore not fixed by the tool; it is fixed by the plugin you select. The README says GraphQL Code Generator "can output code at a wide variety of formats, based on pre-defined templates or based on custom user-defined ones", and that plugins are "very flexible and customizable". The repository layout matches that claim: packages/ holds the published packages, examples/ holds runnable setups such as examples/typescript-graphql-request, examples/typescript-resolvers, examples/react, examples/vue and examples/vite, and dev-test/ is the workspace used to generate and watch output during development. The README also points to a live browser demo for trying the tool without installing it. One consequence of the plugin model is worth stating directly: the core package does not decide what good output looks like. If a plugin generates something you dislike, that is a plugin-level problem, not a bug in the CLI.

Installing GraphQL Code Generator and running a first generation

The README gives the installation commands directly. It installs graphql as a runtime dependency and the CLI as a dev dependency, using pnpm in the example. The same page notes that the complete instructions live on the project website under the getting-started installation path.

pnpm add graphql
pnpm add -D @graphql-codegen/cli

With both packages present, the README's next step is the interactive initializer. It walks through the schema location, the plugins you want, and the destination of the generated file, one question at a time.

The init command and what it produces

The README shows a single command for the guided setup, run through the package manager's script runner rather than npx.

pnpm graphql-codegen init

According to the README, the questions cover setting up a schema, selecting plugins, picking a destination for the generated file, and more. The result is a codegen configuration file that the CLI reads on subsequent runs. The README also offers a manual setup path for people who would rather write that configuration themselves, and links to the website for it. After the initializer finishes, the generated output appears at the destination you chose, and re-running the CLI regenerates it. The README does not document a rollback command, a dry-run flag or a diff mode, so treat the generated files as build artifacts you can delete and recreate rather than something to hand-edit.

Where GraphQL Code Generator is the wrong tool

Generation is a build step, and that shapes its failure modes. If your schema changes while the codegen step is not part of your build or CI, the generated types silently describe an older schema than the one your server exposes, and nothing in the CLI catches that for you unless you run it. The tool also does not replace a GraphQL client at runtime. Generating types for a query does not give you caching, retries, transport or normalisation; those come from whatever client you pair with the generated output, which is why the examples directory contains separate setups for different clients rather than one canonical one. Language coverage is plugin-driven, so a target without a maintained plugin is out of reach unless you write one yourself, and the README frames custom plugins as a supported but hands-on path. Finally, the README is thin on operational detail: it points to the website for installation and does not document rollback, caching behaviour or CI configuration in the repository readme itself.

How it differs from a runtime-first GraphQL client

Apollo Client is the obvious comparison, and the difference is architectural rather than a matter of quality. Apollo Client is a runtime library: it ships a cache, a link chain for transport, hooks and a devtools surface, and it can execute operations without any generation step. GraphQL Code Generator is a build-time tool that emits source files and does not execute anything. In practice they overlap, which is why the related searches include "graphql code generator apollo client": a common setup generates typed hooks for Apollo Client rather than choosing one over the other. The trade-off is where the coupling lives. With a runtime client, your query strings and your types can drift because nothing checks them at build time. With codegen, the build fails or the types go stale when the schema moves, but you own a config file and a generation step in your pipeline. If you want zero build steps and accept weaker static guarantees, the runtime-first route is simpler. If you want the compiler to catch renamed fields, generation is the mechanism that does it.

Maintenance, releases and the MIT licence

The repository is not archived, and its last push was on 2026-09-20, so it is under current development. Recent releases include release-1789911725609 and release-1789878278469, both dated September 20, 2026, and release-20260913-01 from September 13, 2026, which indicates a cadence measured in days rather than months. The repository uses Changesets for release management, visible as the .changeset/ directory and the "release": "changeset publish" script, and Renovate for dependency updates. The workspace is a pnpm monorepo with a pinned packageManager field and an engines requirement of Node >= 16.0.0, so upgrade cost is mostly the cost of moving Node and pnpm versions forward and re-running generation. The licence is MIT, which permits commercial and private use and modification; the README links the licence text, and anyone with specific obligations should read that file rather than rely on this summary. One practical upgrade note: because output is produced by plugins, a plugin upgrade can change generated code even when the CLI version is unchanged, so pinning versions and reviewing generated diffs is the cheap way to keep upgrades boring. The README does not document a deprecation policy for plugins.

Editorial conclusion

Adopt GraphQL Code Generator if you have a GraphQL schema and want generated types or clients in TypeScript, React, Angular, Vue or another supported target, and you are willing to keep a codegen config in sync with your schema. Do not adopt it if you need a runtime library, a server, or a language the plugin list does not cover, and do not expect the README alone to answer configuration questions, since it points to the website for installation details. Verify first that a plugin exists for your exact target and that you can run the CLI in your CI environment with Node 16 or newer, because the repository's package.json sets engines.node to >= 16.0.0.

Frequently asked questions

Official sources

1. dotansimha/graphql-code-generator on GitHub
2. License: MIT
3. Project website
4. README
5. Releases