Skip to content

fix(graphql-language-service-server): import Logger from vscode-jsonrpc#4331

Merged
trevor-scheer merged 1 commit into
graphql:mainfrom
vishwakt:fix/lsp-server-logger-import
Jun 5, 2026
Merged

fix(graphql-language-service-server): import Logger from vscode-jsonrpc#4331
trevor-scheer merged 1 commit into
graphql:mainfrom
vishwakt:fix/lsp-server-logger-import

Conversation

@vishwakt

@vishwakt vishwakt commented Jun 4, 2026

Copy link
Copy Markdown
Contributor

Summary

graphql-language-service-server imported the Logger type from vscode-languageserver, but Logger is defined in vscode-jsonrpc and only reaches vscode-languageserver through a transitive re-export (export * from 'vscode-languageserver-protocol/'). On CI this breaks types:check:

src/GraphQLLanguageService.ts(56,15): error TS2305:
Module '"vscode-languageserver"' has no exported member 'Logger'.

This imports Logger from vscode-jsonrpc instead, which owns the type and is already a direct dependency of the package (vscode-jsonrpc: ^8.0.1), avoiding the fragile re-export chain.

Fixes #4330.

Two separate things are going on

These answer different questions and are both true:

Why it surfaced now (Turborepo cache). graphql-language-service-server#types:check is a cache hit for any PR that does not invalidate it, so the stale green result is reused. Only a PR that changes graphql-language-service (a dependency) busts that cache and forces a real re-run. That is when the latent error becomes visible (it surfaced on #4329, a graphql-language-service change).

Where the type error manifests (platform). When types:check actually runs, it fails on CI (Linux) but passes locally (macOS). The lockfile pins identical dependency versions in both places (vscode-languageserver@8.0.1 -> vscode-languageserver-protocol@3.17.1), so resolution is the only variable. tsgo is @typescript/native-preview, which ships a separate compiled native binary per OS/arch (native-preview-linux-x64 on CI vs native-preview-darwin-arm64 locally), and the pre-release binaries appear to resolve the trailing-slash re-export differently.

I am confident about the cache behavior and the fix. The platform mechanism is my best inference, since I can only test on macOS and cannot directly inspect the Linux tsgo's resolution. Either way the fix is robust because it imports Logger from the package that owns it.

Verification

  • tsgo --noEmit and oxlint pass locally on the changed package.
  • This PR's CI is the real verification: changing this file invalidates the cached types:check and forces a fresh run on Linux, and Types Check (along with all other checks) passes.

Logger is defined and exported by vscode-jsonrpc (a direct dependency) and
only reached vscode-languageserver through a transitive re-export. tsgo failed
to resolve that re-export on CI, breaking types:check with "Module
'vscode-languageserver' has no exported member 'Logger'". Import Logger from
the package that owns the type to avoid the fragile re-export chain.

Closes graphql#4330.
@changeset-bot

changeset-bot Bot commented Jun 4, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: f0e2a93

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
graphql-language-service-server Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@trevor-scheer trevor-scheer left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fix LGTM but is the PR description correct?

My understanding is that this is a turbo cache issue, but the description also says not reproducible on Mac / platform-specific. Are both things true? Platform-specific would be surprising to me.

@vishwakt

vishwakt commented Jun 4, 2026

Copy link
Copy Markdown
Contributor Author

@trevor-scheer Both are true, and they answer two different questions:

  • Why it surfaced on a PR now (Turborepo): graphql-language-service-server#types:check is a cache hit for any PR that doesn't invalidate it, so the stale green result gets reused. Only a PR touching graphql-language-service (a dependency) busts that cache and forces a real re-run, which is what exposed the error.
  • Where the type error actually manifests (platform): when types:check does run for real, it fails on CI (Linux) but passes on my machine (macOS). I agree platform-specificity is surprising for a type error, but tsgo is @typescript/native-preview, which ships a separate compiled native binary per OS/arch (native-preview-linux-x64 on CI vs native-preview-darwin-arm64 locally). A pre-release native compiler resolving the unusual export * from 'vscode-languageserver-protocol/' (trailing slash) differently between platform builds is believable, and the lockfile pins identical dependency versions in both places, so resolution is the only variable left.

To be fully transparent: I'm confident about the Turbo cache behavior and the fix. The platform mechanism is my best inference, since I only have macOS to test on and can't directly inspect the Linux tsgo's resolution. Either way the fix is robust, since it imports Logger from the package that actually owns it (vscode-jsonrpc, already a direct dependency) rather than relying on the transitive re-export.

Happy to tighten the PR description to separate these two points more clearly if that helps.

@trevor-scheer trevor-scheer merged commit e1077b9 into graphql:main Jun 5, 2026
13 checks passed
trevor-scheer pushed a commit that referenced this pull request Jun 6, 2026
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.


# Releases
## codemirror-graphql@2.2.7

### Patch Changes

- Updated dependencies
[[`a526a10`](a526a10)]:
  - graphql-language-service@5.5.2
## @graphiql/react@0.37.6

### Patch Changes

- [#4332](#4332)
[`61d138f`](61d138f)
Thanks [@vishwakt](https://github.com/vishwakt)! - Fix image previews in
the response viewer fetching from the wrong host. Monaco splits the
hovered word on `:`, so a full URL like `https://example.com/img.png`
reaches the preview as the protocol-relative `//example.com/img.png`.
The preview stripped the leading character, turning that into the
host-relative `/example.com/img.png` and fetching it from the current
origin. The original host is now preserved.

- Updated dependencies
[[`a526a10`](a526a10)]:
  - graphql-language-service@5.5.2
## graphql-language-service@5.5.2

### Patch Changes

- [#4329](#4329)
[`a526a10`](a526a10)
Thanks [@vishwakt](https://github.com/vishwakt)! - Make the fields block
optional when parsing object, interface, input, and enum type
definitions (and their extensions) in the online parser. Per the GraphQL
spec these blocks are optional, so spec-valid SDL such as `extend type
Foo @onType` or `type Foo @onType` (directives only, no body) no longer
reports `invalidchar` during syntax highlighting.
## graphql-language-service-server@2.14.10

### Patch Changes

- [#4328](#4328)
[`d6b71ce`](d6b71ce)
Thanks [@vishwakt](https://github.com/vishwakt)! - Move
`debounce-promise` from `devDependencies` to `dependencies`. It is
imported at runtime in `MessageProcessor.ts`, so it must be a regular
dependency. Previously the package only resolved it via hoisting, which
fails under strict installs (e.g. `pnpm` v11), causing `graphql-lsp` to
crash with `Cannot find module 'debounce-promise'`.

- [#4331](#4331)
[`e1077b9`](e1077b9)
Thanks [@vishwakt](https://github.com/vishwakt)! - Import `Logger` from
`vscode-jsonrpc` instead of `vscode-languageserver`. `Logger` is defined
in `vscode-jsonrpc` (a direct dependency) and only reached
`vscode-languageserver` through a transitive re-export, which `tsgo`
failed to resolve on CI (`Module '"vscode-languageserver"' has no
exported member 'Logger'`). Importing from the package that owns the
type avoids relying on that fragile re-export chain.

- Updated dependencies
[[`a526a10`](a526a10)]:
  - graphql-language-service@5.5.2
## vscode-graphql-execution@0.3.6

### Patch Changes

- [#4306](#4306)
[`7aefde8`](7aefde8)
Thanks [@dependabot](https://github.com/apps/dependabot)! - Bump `ws` to
8.20.1 to address
[GHSA-58qx-3vcg-4xpx](GHSA-58qx-3vcg-4xpx)
(uninitialized memory disclosure in `websocket.close()`).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[lsp-server] 🐞 types:check fails on Logger import, masked by Turborepo cache

2 participants