chore(lsp): migrate to language client/server v10 + protocol 3.18#614
Merged
Conversation
…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>
a91de98 to
ce56733
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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-languageserverv10 expose their/nodeentrypoints through the packageexportsfield. The LSP tsconfigs usedmoduleResolution: "node"(classic), which cannot readexports, producingTS2307: Cannot find module 'vscode-languageclient/node'and a cascade of missing Node globals (path,console,__dirname, ...).Changes
vscode-languageclient9 -> 10 (client).vscode-languageserver9 -> 10 andvscode-languageserver-protocol3.17 -> 3.18 (server).module/moduleResolution: "node16"so theexports-based entrypoints resolve. Because neitherpackage.jsondeclares"type": "module", node16 keeps CommonJS emit -- which is required, since the e2e harness runsclient/out/test/*.jsdirectly under Node and the extension loadsserver/out/server.js-- and it uses CommonJS resolution, so the server'simport * as wasm from "../pkg/"directory specifier still resolves. (bundler/esnextwould emit ESM and break the Node-executed harness.)typesarray 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