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

[vishwakt]

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.

[changeset-bot]

🦋 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]

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]

@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.