# GraphQL Zeus turns a selector object into a typed query, and its last release was 7.0.1

> graphql-zeus is an MIT-licensed TypeScript code generator that reads a GraphQL schema and emits types plus a strongly typed client, where queries are written as nested objects validated at compile time. It suits teams that want Apollo-compatible typed calls without hand-maintaining fragments, and the listed release is 7.0.1, with the repository last pushed on 2026-04-07.

**graphql-editor/graphql-zeus** — GraphQL client and GraphQL code generator with GraphQL autocomplete library generation ⚡⚡⚡ for browser,nodejs and react native ( apollo compatible ) 

- Repository: https://github.com/graphql-editor/graphql-zeus
- Website: https://zeus.aexol.com
- Stars: 1,977 · Forks: 110
- Language: TypeScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/graphql-editor-graphql-zeus

## The core idea: a query is an object, not a string

Zeus is a code generator plus a client library. You run its CLI against a GraphQL schema file and it emits TypeScript types and a client into a directory you choose.

What it generates is unusual compared with most GraphQL codegen tools. The README contrasts a conventional GraphQL query string with a Zeus query written as a nested object literal:

```tsx
{
  usersQuery: {
    admin: {
      sequenceById: [
        { id: $("id", "String!") },
        {
          _id: true,
          name: true,
          analytics: { ...fields("SequenceAnalytics") },
          replies: {
            ...fields("SequenceTrackReply"),
          },
          messages: {
            ...fields("Message"),
          },
          tracks: {
            ...fields("SequenceTrack"),
            contact: {
              linkedInId: true,
            },
          },
        },
      ],
    },
  },
}
```

Two things are happening in that structure. The field name `sequenceById` is a key, and its value is an array where the first element is the arguments, expressed with `$()` carrying the variable name and its GraphQL type, and the second element is the selection set with `true` marking a scalar field.

Because it is an object literal rather than a string, TypeScript checks it. Misspell a field and it fails to compile. Request a field that does not exist on that type and it fails to compile. Pass an argument of the wrong type and it fails to compile. The README's feature list names this as validating queries and selectors.

The runtime cost is that the client walks the object to build the query string, so the type safety is bought at compile time and paid for with a serialisation step.

## Installing the CLI, and the --node difference

Install it globally, or locally and run it through npx or yarn:

```
$ npm i -g graphql-zeus
```

The local form avoids a global install:

```
$ npx zeus schema.graphql ./
```

Generation takes a schema file and an output directory. The first argument is the schema, the second is where the generated code lands.

There is one flag that matters and the README shows it in a table with two columns, NodeJS and React Native:

| For NodeJS                          | For React Native                 |
|-------------------------------------|----------------------------------|
| `$ zeus schema.graphql ./ --node`   | `$ zeus schema.graphql ./`       |

So `--node` selects the Node.js flavour of the generated client and the bare command targets React Native. Given the package description says it works in browser, Node.js and React Native, that flag is choosing the platform-specific fetch and runtime wiring rather than changing the query syntax.

For TypeScript projects the README notes Zeus is TypeScript native and you can refer to the imported types directly from the generated output. That matters because the point of the tool is types, and importing them directly rather than re-declaring them is how you keep them in sync with regeneration.

## Composables: share a base selection and vary the extra fields

The composables API is the feature the version 7 release notes call out, and the repository ships an `llms.md` file that suggests the project is documenting itself for language models.

The pattern is a function that takes an id and a rest of the selection, and returns a query. The README's example names a helper `withComposable` typed against `ComposableSelector`:

```ts
import {
  Gql,
  ComposableSelector,
} from './zeus/index.js';

const withComposable = <T extends ComposableSelector<'Card'>, Z extends T>(id: string, rest: Z | T) =>
  Gql('query')({
    cardById: [{ cardId: id }, rest],
  });
  const c1result = await withComposable('12', {
    id: true,
  });
  const c2result = await withComposable('12', {
    Defense: true,
    Attack: true,
  });
```

Both responses and inputs are described as safely typed. The point of the helper is that the base fields live in one place and each caller adds its own, so a card component and a deck component can share the card selection without duplicating it.

That is the same job as a fragment, and the feature list describes reusable selection sets as fragments-like. Composables go further by letting the extra fields be chosen per call while keeping the shape typed. If your project already has a fragment convention, this is the part of Zeus that overlaps with it, and worth evaluating before you adopt both.

## The features list, read as a scope statement

Beyond typed queries, the README's feature list names: types mapped from your schema; fetching all primitive fields with one function; working with Apollo Client, React Query and Stucco Subscriptions; support for subscriptions; inference of complex response types; reusable selection sets; support for unions, interfaces, aliases and variables; handling of massive schemas; support for browsers, Node.js and React Native in both JavaScript and TypeScript; a schema downloader; and JSON schema generation.

Three entries deserve unpacking.

The description calls Zeus Apollo compatible, while the feature list says it works with Apollo Client.

Fetching all primitive fields with one function is what `...fields("Message")` does in the example above, a generated helper that expands to every scalar on that type. It is the single most useful line for someone who does not want to enumerate fields by hand, and it is also the line that silently changes shape when your schema adds a field.

The schema downloader is the piece that closes the loop, because it means the CLI can fetch a schema from a live endpoint rather than requiring you to keep a checked-in `.graphql` file in sync by hand.

JSON schema generation is a separate output, and the repository root has `packages/graphql-zeus-jsonschema` as a workspace alongside `graphql-zeus-core`, so it is a distinct package rather than a flag.

## Apollo compatibility means you keep your own transport

The Apollo Client line deserves its own section because it changes what Zeus is and is not.

Zeus is not a GraphQL client in the sense of owning your network layer. It generates types, a query builder, and a fetch function, and the feature list places Apollo Client, React Query and Stucco Subscriptions alongside each other as things it works with. The README lists Apollo Client, React Query and Stucco Subscriptions as integrations with which Zeus works.

This is a materially different architecture from the string-based clients it resembles. With a string query, the response type is a generic `any` or a hand-written interface, and a mismatch surfaces as a runtime undefined. With Zeus, the generated types flow from the same schema the query was checked against, so the compiler rejects a field that the response will not contain.

The trade is that you now have a build step and generated files in your repository. Regeneration has to happen when the schema changes, and a merge conflict in generated output is a category of problem you do not have with a hand-written string query.

If your team does not want codegen in its build, that cost is decisive regardless of the type safety.

## Version 7.0.1 is the only tagged release, and there has been a pause

The listed release is version 7.0.1, dated 2024-11-02, described as GraphQL Zeus 7 with fetching all fields with one selector, null support, and dropped constant enums.

That release note is unusually informative about breaking changes. Null support was added, meaning nullable fields are handled explicitly rather than assumed absent. Constant enums were dropped, which is a removal rather than an addition and would break code generated by an earlier version.

The repository is not archived, and the last push was on 2026-04-07, which is more than six months before this review. The repository is not archived, and the listed release dates from November 2024.

That gap is the thing to weigh. A code generator whose output shape changes with each major version needs either frequent releases or a clear migration story, and the latest listed release leaves you choosing between version 7.0.1 and newer work on master.

Two other signals are worth noting. The repository is commitizen friendly, with commitlint and a conventional changelog setup, which suggests release discipline is intended even if the cadence has slowed. And the default branch is master rather than main, which tells you the project predates that convention and has not been modernised.

## Repository layout: three workspaces and an example project

The root package.json is a private workspace root named `graphql-zeus-repo` at version 0.0.2, and the published package is a different one, `graphql-zeus`.

The workspaces list includes `packages/graphql-zeus-core` and `packages/graphql-zeus-jsonschema`, and the scripts reference `packages/graphql-zeus/lib/index.js` for the `cli` script, so the tree splits into the schema-to-TypeScript core, a JSON schema output package, and the CLI wrapper.

There is one runnable example, `examples/typescript-node`, driven by `run-example.sh`, which the `run-example-typescript-node` script invokes. One example is thin coverage for a tool whose main risk is environment setup, so expect to spend time reading the documentation site rather than copying a repository example.

The toolchain is dated in a way that affects contributions rather than usage. The devDependencies pin typescript to 4.8.4 exactly, with eslint 8, prettier 2.7 and @typescript-eslint 5, plus `ttypescript` and `typescript-transform-paths`, which are the tools used to apply custom transforms during the build. If you want to send a patch, you are working against that toolchain rather than a current one.

Testing is jest through ts-jest, configured in jest.config.js.

## When a string query is the better choice

The case against Zeus is not that it does not work, it is that the generated-code cost is real in specific situations.

A project with no type checker gets nothing. The entire benefit is that a bad query is a compile error, and in a JavaScript project with JSDoc and no enforcement there is no compile step to fail. The feature list does say the library supports JavaScript, but the reason to choose it over a string is much weaker there.

A project with one endpoint and one query also gets little. Setup, codegen and regeneration cost more than writing ten query strings by hand.

A project where the schema changes daily is a poor fit, because every change means regenerating, and you are now merging generated diffs on every pull. This is the profile of an organisation where several teams change a shared schema independently.

A project with strong existing codegen gets less benefit too. If you already use a typed client generator that produces string queries with response types, Zeus's advantage narrows to its selector validation.

And where the schema is unstable in shape, the `fields()` helper is a hazard rather than a convenience, since it expands to whatever scalars exist at generation time, so a newly added field appears in your response without anyone changing the query.

On the other side, a large TypeScript codebase querying several GraphQL services with unions, interfaces and shared selection sets is exactly the profile the tool is built for, and writing that by hand is genuinely painful.

## Conclusion

Adopt GraphQL Zeus if your TypeScript project queries several GraphQL endpoints and you want compile-time validation of queries and selectors, since that is what the generated object literal buys you over a string. Do not adopt it for a JavaScript project with no type checker, because the main benefit is a type error rather than a runtime one. Verify first which version you pin, since the README's documented feature set includes composables added for version 7 and the listed release is 7.0.1 from 2024-11-02, with the last push on 2026-04-07.

## FAQ

### How do I install GraphQL Zeus?

Install it globally with npm i -g graphql-zeus or yarn global add graphql-zeus, or install it locally and run it through npx or yarn as npx zeus schema.graphql ./. The first argument is the schema file and the second is the output directory.

### What does the --node flag do in GraphQL Zeus?

The README's generation table shows `zeus schema.graphql ./ --node` for NodeJS and `zeus schema.graphql ./` for React Native, so the flag selects the platform flavour of the generated client.

### How does GraphQL Zeus validate queries at compile time?

Queries are written as nested object literals whose keys are field names and whose values are argument tuples plus a selection set with true for scalar fields. Because it is an object rather than a string, TypeScript rejects unknown fields, wrong argument types and invalid selections at build time.

### Does GraphQL Zeus work with Apollo Client?

Yes. The repository description calls Zeus Apollo compatible, and the feature list names Apollo Client, React Query and Stucco Subscriptions as things it works with, and the feature list names it among the integrations supported by Zeus.

### What changed in GraphQL Zeus version 7?

Release 7.0.1, tagged 2024-11-02, is described as fetching all fields with one selector, adding null support, and dropping constant enums. Dropping constant enums is a removal, so code generated by an earlier major version will need regenerating.

### What licence is GraphQL Zeus released under?

It is released under the MIT licence, with LICENSE.md at the repository root and license declared as MIT in package.json. This is a licensing note and not legal advice.

## Sources

- [graphql-editor/graphql-zeus on GitHub](https://github.com/graphql-editor/graphql-zeus)
- [License: MIT](https://github.com/graphql-editor/graphql-zeus/blob/master/LICENSE)
- [Project website](https://zeus.aexol.com)
- [README](https://github.com/graphql-editor/graphql-zeus/blob/master/README.md)
- [Releases](https://github.com/graphql-editor/graphql-zeus/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/graphql-editor-graphql-zeus