Skip to content

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

Description

@vishwakt

Is there an existing issue for this?

  • I have searched the existing issues

Summary

graphql-language-service-server imports Logger from vscode-languageserver:

// packages/graphql-language-service-server/src/GraphQLLanguageService.ts:56
import type { Logger } from 'vscode-languageserver';

On CI (Linux), this fails type checking:

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

Logger is defined in vscode-jsonrpc and only reaches vscode-languageserver through a re-export chain. vscode-languageserver's entry does:

export * from 'vscode-languageserver-protocol/'; // note the trailing slash

tsgo (the TypeScript native preview the repo migrated to in #4274) appears to resolve that trailing-slash re-export differently across platforms, so Logger is not visible from vscode-languageserver on CI.

Why it has gone unnoticed

The error is latent and masked by Turborepo's 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 the cache and forces a real re-run, which is when the error surfaces.

This is currently visible on #4329, whose graphql-language-service change invalidates the cache (cache miss, executing bf0aa89f182b2312). Other open PRs still pass types:check because their cached result is reused.

Evidence

  • Locally (macOS), yarn types:check produces the same Turbo hash CI computes (bf0aa89f182b2312) and passes (24/24), so this is not a source-logic issue, it is environment/resolution specific.
  • The lockfile pins vscode-languageserver@8.0.1 -> vscode-languageserver-protocol@3.17.1, so the resolved versions are identical on CI and locally. The difference is in how tsgo resolves the trailing-slash re-export per platform.

Proposed fix

Import Logger directly from vscode-jsonrpc, which defines and exports it, and which graphql-language-service-server already lists as a direct dependency (vscode-jsonrpc: ^8.0.1):

import type { Logger } from 'vscode-jsonrpc';

This avoids relying on the fragile transitive re-export chain. (Same dependency-hygiene class as #4324.)

Environment

  • LSP Server Version: graphql-language-service-server on main
  • CI: GitHub Actions, Linux, tsgo (@typescript/native-preview 7.0.0-dev.20260418.1)
  • Not reproducible on macOS with the same lockfile/tsgo, so CI is the verification path

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions