Skip to content

chore(lsp): migrate to language client/server v10 + protocol 3.18#614

Merged
anweiss merged 1 commit into
mainfrom
chore/lsp-v10-migration
Jun 29, 2026
Merged

chore(lsp): migrate to language client/server v10 + protocol 3.18#614
anweiss merged 1 commit into
mainfrom
chore/lsp-v10-migration

Conversation

@anweiss

@anweiss anweiss commented Jun 29, 2026

Copy link
Copy Markdown
Owner

Supersedes Dependabot PRs #609, #608 and #575, which each failed CI on their own because the v10 packages require a module-resolution change to build.

Why they failed

vscode-languageclient/vscode-languageserver v10 expose their /node entrypoints through the package exports field. The LSP tsconfigs used moduleResolution: "node" (classic), which cannot read exports, producing TS2307: Cannot find module 'vscode-languageclient/node' and a cascade of missing Node globals (path, console, __dirname, ...).

Changes

  • Bump vscode-languageclient 9 -> 10 (client).
  • Bump vscode-languageserver 9 -> 10 and vscode-languageserver-protocol 3.17 -> 3.18 (server).
  • Switch both LSP tsconfigs to module/moduleResolution: "node16" so the exports-based entrypoints resolve. Because neither package.json declares "type": "module", node16 keeps CommonJS emit -- which is required, since the e2e harness runs client/out/test/*.js directly under Node and the extension loads server/out/server.js -- and it uses CommonJS resolution, so the server's import * as wasm from "../pkg/" directory specifier still resolves. (bundler/esnext would emit ESM and break the Node-executed harness.)
  • Add an explicit types array to each tsconfig so auto-included @types (Node/Mocha/VS Code globals) keep resolving under the new resolver.

Verification (local)

  • tsc -b ./client/tsconfig.json ./server/tsconfig.json -> clean, emits CommonJS.
  • npm run webpack (the CI build step, incl. wasm-pack) -> both client and server bundles compile successfully.

Closes #609
Closes #608
Closes #575

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

…3.18

Supersedes the individual Dependabot bumps #609, #608 and #575, which
failed CI because vscode-languageclient/server v10 expose their `/node`
entrypoints via the package `exports` field, which the classic
`moduleResolution: "node"` setting cannot resolve (TS2307 on
`vscode-languageclient/node`, cascading into missing Node globals).

- Bump vscode-languageclient 9 -> 10 (client) and vscode-languageserver
  9 -> 10 plus vscode-languageserver-protocol 3.17 -> 3.18 (server).
- Switch both LSP tsconfigs to `module`/`moduleResolution: "node16"` so
  the `exports`-based entrypoints resolve. Because neither package.json
  declares `"type": "module"`, node16 keeps CommonJS emit (required: the
  e2e harness runs `client/out/test/*.js` directly under Node, and the
  extension loads `server/out/server.js`) and uses CommonJS resolution,
  so the server's `import * as wasm from "../pkg/"` directory specifier
  still resolves.
- Pin the auto-included `@types` via an explicit `types` array so Node
  globals continue to resolve under the new resolver.

Verified locally: `tsc -b` for client and server emit CommonJS, and the
full `npm run webpack` production build succeeds.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@anweiss anweiss force-pushed the chore/lsp-v10-migration branch from a91de98 to ce56733 Compare June 29, 2026 21:28
@anweiss anweiss merged commit b047460 into main Jun 29, 2026
17 checks passed
@anweiss anweiss deleted the chore/lsp-v10-migration branch June 29, 2026 21:31
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.

1 participant