GraphiQL and the GraphQL LSP ecosystem: what the graphql/graphiql monorepo actually ships

What problem the graphql/graphiql monorepo solves

GraphQL APIs are self-describing, and that description is the whole point: a client can ask the server for its schema and then write queries against fields that actually exist. Getting that loop into a developer's editor is a separate engineering problem, and it is the one this repository addresses. The monorepo is an official project under the GraphQL Foundation, and its stated purpose is to give the community a to-specification language service, an LSP server and CLI for IDEs, a CodeMirror mode, a Monaco mode described as in the works, and an example of how to use the whole ecosystem with GraphiQL.

The audience is therefore not end users of a GraphQL API. It is people building the tooling layer: a server team that wants to serve an explorer alongside its endpoint, a framework author embedding an editor, or an IDE extension author who needs completion, linting and typeahead driven by a live schema. If you only want to send queries to an API, a browser tab pointed at a running GraphiQL instance is enough, and you never need to read this repository at all.

How the packages fit together: language service, editors, LSP server

The architecture is layered, and the layering is the useful part. At the bottom sits graphql-language-service, which the README describes as providing language services for three consumers: the server package, codemirror-graphql and monaco-graphql. It was previously published as four separate packages (graphql-language-service-interface, graphql-language-service-parser, graphql-language-service-utils and graphql-language-service-types), all now retired and folded into one. That consolidation matters if you are upgrading an old integration: the old package names no longer receive releases.

Above it sit the editor integrations. codemirror-graphql targets CodeMirror 5 and supplies a parser mode plus a live linter and typeahead hinter powered by the schema. cm6-graphql does the same job for CodeMirror 6, described as a full-featured language mode. monaco-graphql supplies Monaco with a schema-driven mode and uses graphql-language-service directly. The GraphiQL IDE itself is a React application built on the CodeMirror mode and the language service, which is why the root README points to packages/graphiql/README.md for full documentation rather than repeating it.

Off to the side of the browser stack is graphql-language-service-server, which exposes the same language services over LSP for IDE extensions, and graphql.vscode-graphql, the example implementation of that server for Visual Studio Code. There is no shared runtime between the browser path and the LSP path; they share the language service and diverge at the transport.

Installing graphiql and mounting a first IDE

The repository is a pnpm workspace. The root package.json declares packageManager [email protected], so the workspace expects pnpm rather than npm or yarn for development. The root package is private and versioned 0.0.0; nothing here is published under the monorepo name.

For a local checkout of the IDE, the root scripts expose a filtered dev task:

pnpm install
pnpm dev:graphiql

The dev:graphiql script runs turbo watch dev filtered to the graphiql package, so you get a watching dev server for the IDE package rather than the whole workspace. The README also links a Netlify build of the main branch and a live demo at graphql.org/swapi-graphql if you would rather look before installing.

If you are consuming the IDE in your own application instead of developing the monorepo, the relevant package is graphiql, published on npm, and the full integration documentation lives in packages/graphiql/README.md. The root README does not reproduce the component API, so treat that package README as the source for props, plugin wiring and the fetcher contract. For an editor mode rather than the full IDE, the choice is between codemirror-graphql (CodeMirror 5), cm6-graphql (CodeMirror 6) and monaco-graphql (Monaco); each is published separately on npm and each depends on graphql-language-service.

The examples directory is the practical starting point, because it contains runnable integrations rather than prose: examples/graphiql-cdn, examples/graphiql-create-react-app, examples/graphiql-nextjs, examples/graphiql-parcel, examples/graphiql-vite, examples/graphiql-vite-react-router and examples/graphiql-webpack, plus Monaco variants including examples/monaco-graphql-webpack, which the README describes as a plain JavaScript demo using the GitHub API.

The XSS advisory is the first thing to check, not the last

The root README opens with a security notice rather than burying it: all versions of graphiql below 1.4.7 are vulnerable to an XSS attack in cases where the GraphQL server the web app connects to is not trusted, with details in the docs/security directory. That framing is unusually direct, and it encodes a real design assumption. GraphiQL is built to talk to a server you control. Point it at an arbitrary endpoint and you are trusting that endpoint's responses inside your own origin.

If your dependency tree still resolves an older graphiql, the fix is a version bump, not a configuration change. The advisory does not describe a mitigation short of upgrading, and the README does not document rollback or a compatibility shim for pre-1.4.7 releases. The practical consequence is that pinned versions in a lockfile deserve a check before you evaluate anything else about the stack.

Where the monorepo is the wrong tool

The repository is a library and IDE ecosystem, not a hosted product. There is no account system, no saved query history service and no team workspace in what the README describes. If your requirement is a shared playground where colleagues store and replay queries, this stack gives you the editor component and leaves persistence, authentication and multi-user concerns entirely to you.

A second boundary is the desktop story. The README frames GraphiQL as an in-browser IDE and mentions advanced web or desktop experiences as something you might build for your framework or plugin, not as something shipped here. Anyone looking for a maintained desktop GraphQL client will not find one in this repository.

Third, the Monaco mode is described in the README's own overview as in the works. That is the project's wording, and it should temper expectations about API stability for monaco-graphql relative to the CodeMirror path, which the IDE itself depends on. Finally, the LSP server is aimed at IDE extension authors over the Language Server Protocol. If your editor already has a GraphQL extension you are happy with, adopting graphql-language-service-server directly buys you nothing.

GraphiQL versus Apollo Sandbox and the other explorers

The obvious comparison is with hosted explorers such as Apollo Sandbox, and the difference is one of ownership rather than features. GraphiQL is a component you install and serve yourself, under the MIT license, and it is the reference implementation maintained under the GraphQL Foundation. A hosted explorer is a service someone else runs: you point a browser at it, and schema introspection happens from their origin to yours. If your endpoint is not reachable from the public internet, or your security review does not permit third-party origins, the self-hosted component is the only one of the two that works.

The trade is operational. Self-hosting means you own the build, the version bumps and the XSS exposure described above. A hosted explorer moves that maintenance elsewhere at the cost of control and of depending on a vendor's continued operation. Within the self-hosted category, the choice between GraphiQL and other embedded explorers usually comes down to which editor stack you already run: codemirror-graphql, cm6-graphql and monaco-graphql are all published separately, so you can take the language service without taking the full IDE.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-17, so it is being worked on. The release cadence is visible in the package-level tags: [email protected] on 2026-09-09, [email protected] and [email protected] both on 2026-08-30. Releases are cut per package, not as a single monorepo version, which is why the root package.json sits at 0.0.0 and is marked private.

That per-package versioning is the main upgrade cost. There is no single version number to track; you follow graphiql, your editor mode package and graphql-language-service independently, and the changesets directory plus CHANGELOG.md are where the project records what moved. Upgrading the language service under an editor mode that has not been released against it is the kind of mismatch the layered design invites.

The licence is MIT, stated in both the root README and the root package.json. That is permissive and permits commercial use and redistribution, but it comes with no warranty, and the security notice above shows what that means in practice: the XSS fix reached users through a version bump, not through a support contract. This is a description of the licence terms, not legal advice; if the terms matter to your organisation, read the LICENSE file.

Editorial conclusion

Adopt it if you want the reference GraphiQL IDE in a React app, or the official language service behind an editor mode. Skip it if you need a maintained desktop client or a hosted playground with saved history. Before anything else, check the graphiql version you depend on against the XSS advisory in docs/security, then read packages/graphiql/README.md for the current props and plugin API.

Frequently asked questions

Official sources

1. graphql/graphiql on GitHub
2. Issues
3. License: MIT
4. README
5. Releases