[lsp-server] 🐞 documents scan does not skip node_modules, slow startup in monorepos

Open Beginner friendly
  • Is something wrong?
#4,614 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@shubhamrai9122-creator is already working on this.

Since Oct 10, 2026.

  • #4622 by @shubhamrai9122-creator — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
84/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
graphql, typescript
Domain
devtools, performance

Research direction

Start at _cacheDocumentFilesforProject, where startup pre-caches each project's documents, and inspect how project.loadDocuments receives the project's exclude values. Verify that the completed behavior skips node_modules by default while preserving explicit exclusions, then compare cache initialization behavior for the reproduction configuration.

Written by the indexing model from the issue text.

Description

Is there an existing issue for this?
  • I have searched the existing issues
Current Behavior

At startup the server pre-caches every project's documents via project.getDocuments(). graphql-tools does not ignore node_modules by default, so a root-level glob such as documents: "**/*.api.gql" walks the whole node_modules tree (in a pnpm monorepo, all package node_modules too), once per project.

Measured in a pnpm monorepo with three projects (warm FS cache; the same 32/13/7 files are found in every case):

exclude glob time
none ~1.2 s per project
**/node_modules/** 263 ms for all three

Cold, the first GraphQL Language Server caches initialized arrived ~15 s after initialize. Hover, completion and go-to-definition all return nothing until then.

Expected Behavior

node_modules is skipped when loading documents unless the user explicitly includes it. Documents inside node_modules are almost never wanted.

Steps To Reproduce
  1. Monorepo with a large node_modules.
  2. graphql.config.js with documents: "**/*.graphql" and no exclude.
  3. Restart the LSP and compare the time between initialize and caches initialized with and without exclude: "**/node_modules/**".
Environment
  • LSP Server Version: 2.15.0 (main @ bc13647b)
  • OS: macOS
  • LSP Client: vscode-graphql 0.13.x
  • LSP Install Source: vscode marketplace
Anything else?

Workaround: exclude: ["**/node_modules/**"] on each project (graphql-config passes exclude as the glob ignore list). Adding the default in _cacheDocumentFilesforProject (e.g. project.loadDocuments(project.documents, { ignore: [...asArray(project.exclude ?? []), '**/node_modules/**'] })) would fix it for everyone. A negated !**/node_modules/** inside documents is not a good workaround: it makes graphql-config's match() claim every file outside node_modules.

Dominant language
TypeScript
Stars
16.9k
Forks
1.9k
Avg merge
14h 1m
Merged PRs (30d)
81

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from graphql/graphiql

All issues in graphql/graphiql

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.