[Snyk] Security upgrade vscode-languageclient from 9.0.1 to 10.0.0#9900
[Snyk] Security upgrade vscode-languageclient from 9.0.1 to 10.0.0#9900rubenfiszel wants to merge 1 commit into
Conversation
…nerabilities The following vulnerabilities are fixed with an upgrade: - https://snyk.io/vuln/SNYK-JS-BRACEEXPANSION-17706650
|
This is a major version upgrade from 9.x to 10.x which introduces significant and mandatory breaking changes for developers. The new version aligns with Language Server Protocol (LSP) version 3.18. Key Breaking Changes:
Recommendation: Source: vscode-languageserver-node Releases
|
Deploying windmill with
|
| Latest commit: |
3607ff1
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://81b7543b.windmill.pages.dev |
| Branch Preview URL: | https://snyk-fix-1796a9f5d79c2fcaced.windmill.pages.dev |
|
Claude finished @rubenfiszel's task in 2m 27s —— View job cc @rubenfiszel Should address issues before merging: version split breaks the Monaco LSP integration, and the fix is likely ineffectiveDo not merge this Snyk upgrade as-is. Bumping the direct
The core problem:
|
| Consumer | vscode-languageclient | jsonrpc / protocol |
|---|---|---|
| root (direct import) | 10.0.0 | vscode-jsonrpc 9.0.0, protocol 3.18.0 |
monaco-languageclient/node_modules/… |
9.0.1 (new nested copy) | vscode-jsonrpc 8.x, protocol 3.17.5 |
Before this PR there was a single, deduplicated vscode-languageclient@9.0.1 shared by both. The direct dependency almost certainly exists to pin that shared copy. Bumping it to 10 defeats that and creates the split.
Why the split is a runtime risk (P1)
frontend/src/lib/components/Editor.svelte mixes both copies in a single client instance:
Editor.svelte:25—MonacoLanguageClientfrommonaco-languageclient→ built against v9 (jsonrpc 8)Editor.svelte:28-29—CloseAction, ErrorAction, RequestType, MessageTransportsfromvscode-languageclient→ now resolve to v10 (jsonrpc 9)Editor.svelte:948—new MonacoLanguageClient({ messageTransports: transports, … })feeds a v10MessageTransportsinto a v9 clientEditor.svelte:470, 1070—client.sendRequest(new RequestType('…'), …)passes a v10RequestType(from vscode-jsonrpc 9) to a v9 connection
ErrorAction/CloseAction are numeric enums and probably survive, but RequestType/MessageTransports are class instances from vscode-jsonrpc, whose reader/writer/RequestType contracts changed between v8 and v9. Crossing them into a v9-based MonacoLanguageClient can break message registration/transport wiring — i.e. LSP autocomplete, formatting (textDocument/formatting), hover, and deno/cache in the editor. This is not covered by any test and would only surface at runtime in the browser.
The upgrade may not even fix the vulnerability
The nested monaco-languageclient/node_modules/vscode-languageclient@9.0.1 still pulls minimatch@5.1.9 → brace-expansion@2.1.1. So the v9 → minimatch@5 → brace-expansion chain the advisory targets is still present, just relocated under monaco-languageclient. Please confirm with npm audit / the Snyk report that SNYK-JS-BRACEEXPANSION-17706650 is actually resolved after this change — the direct-dep bump only patches the root copy.
Minor: spec mismatch
package.json records ~10.0.0 but package-lock.json records the root dep as ^10.0.0 (package-lock.json:76). A clean npm install will want to reconcile these.
Recommendation
If the brace-expansion transitive is the real concern, prefer a targeted overrides in package.json instead of force-upgrading a major version that monaco-languageclient doesn't support:
"overrides": {
"brace-expansion": "^2.0.2"
}Otherwise, keep vscode-languageclient at ~9.0.1 (matching monaco-languageclient@10.6.0) and revisit the v10 upgrade only when monaco-languageclient bumps its own pin. Fix this →
Test coverage
Config/lockfile-only change — no automated tests expected, and the codebase doesn't test the Monaco editor component. Manual verification is essential before any merge: open a script editor (e.g. a Deno/TypeScript or Python script), confirm the language server connects and that autocomplete, hover, go-to-definition, and format-on-save still work, and check the browser console for vscode-jsonrpc/languageclient errors. Given the v9/v10 split above, I'd expect problems there.
Codex ReviewGood to merge Found 0 issues. Checked for bugs, security impact, dependency consistency, and AGENTS.md compliance. Test coverage This is a frontend dependency metadata update only; no new automated tests are expected. I validated the lockfile with Manual verification: smoke-test the Monaco editor language-server path for a Deno/Python/Go/Shell script and confirm the websocket client starts, completions/signature help work, and the browser console has no new errors. |
Pi ReviewShould address issues before merging: verify build + editor LSP works after major version bump The P1 — Untested major-version dependency upgrade with dual-version coexistenceFile:
These all appear likely to work, but nothing in CI actually exercises the Monaco editor with an LSP connection (the editor is a browser-only component). The upgrade should be verified by running Test coverage
Manual verification needed before merge: Run |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
3 issues found across 2 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="frontend/package-lock.json">
<violation number="1" location="frontend/package-lock.json:79">
P2: Version specifier mismatch: `package.json` declares `~10.0.0` (tilde — only patch updates) but `package-lock.json` records `^10.0.0` (caret — minor + patch updates) for the same dependency. This inconsistency means a clean `npm install` may produce a different lockfile, causing CI/CD or teammate reproducibility issues.</violation>
<violation number="2" location="frontend/package-lock.json:9455">
P1: The vulnerability this PR intends to fix (`SNYK-JS-BRACEEXPANSION-17706650`) may still be present. The nested `monaco-languageclient/node_modules/vscode-languageclient@9.0.1` still pulls `minimatch@5.1.9` → `brace-expansion@2.1.1` (visible in the lockfile). The major version bump only patches the *root* copy's transitive chain; the nested copy retains the vulnerable path. Please verify with `npm audit` that the advisory is actually resolved after this change.</violation>
</file>
<file name="frontend/package.json">
<violation number="1" location="frontend/package.json:154">
P1: Upgrading `vscode-languageclient` to 10.0.0 while `monaco-languageclient@10.6.0` pins `~9.0.1` creates a dependency fork: npm installs both v10 at the root and a nested v9.0.1 under `monaco-languageclient/node_modules/`. The frontend's `Editor.svelte` imports `MonacoLanguageClient` (which internally uses jsonrpc 8.x from the nested v9 copy) alongside `RequestType` and `MessageTransports` (which now resolve to jsonrpc 9.x from the root v10 copy). Passing v10 class instances into a v9-based client can break LSP transport wiring at runtime — autocomplete, hover, formatting, and similar language features would silently fail.
Consider keeping `vscode-languageclient` at `~9.0.1` to match what `monaco-languageclient` expects, and instead use an npm `overrides` entry to patch the transitive `brace-expansion` vulnerability:
```json
"overrides": {
"brace-expansion": "^2.0.2"
}
```</violation>
</file>
Heads up: you’re close to your included review allowance. Set a flex budget so reviews don’t pause.
Fix all with cubic | Re-trigger cubic
| "integrity": "sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==", | ||
| "license": "MIT" | ||
| }, | ||
| "node_modules/monaco-languageclient/node_modules/brace-expansion": { |
There was a problem hiding this comment.
P1: The vulnerability this PR intends to fix (SNYK-JS-BRACEEXPANSION-17706650) may still be present. The nested monaco-languageclient/node_modules/vscode-languageclient@9.0.1 still pulls minimatch@5.1.9 → brace-expansion@2.1.1 (visible in the lockfile). The major version bump only patches the root copy's transitive chain; the nested copy retains the vulnerable path. Please verify with npm audit that the advisory is actually resolved after this change.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At frontend/package-lock.json, line 9455:
<comment>The vulnerability this PR intends to fix (`SNYK-JS-BRACEEXPANSION-17706650`) may still be present. The nested `monaco-languageclient/node_modules/vscode-languageclient@9.0.1` still pulls `minimatch@5.1.9` → `brace-expansion@2.1.1` (visible in the lockfile). The major version bump only patches the *root* copy's transitive chain; the nested copy retains the vulnerable path. Please verify with `npm audit` that the advisory is actually resolved after this change.</comment>
<file context>
@@ -9446,6 +9446,47 @@
+ "integrity": "sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==",
+ "license": "MIT"
+ },
+ "node_modules/monaco-languageclient/node_modules/brace-expansion": {
+ "version": "2.1.1",
+ "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.1.1.tgz",
</file context>
| "unist-util-visit": "^5.0.0", | ||
| "vscode": "npm:@codingame/monaco-vscode-extension-api@=25.0.0", | ||
| "vscode-languageclient": "~9.0.1", | ||
| "vscode-languageclient": "~10.0.0", |
There was a problem hiding this comment.
P1: Upgrading vscode-languageclient to 10.0.0 while monaco-languageclient@10.6.0 pins ~9.0.1 creates a dependency fork: npm installs both v10 at the root and a nested v9.0.1 under monaco-languageclient/node_modules/. The frontend's Editor.svelte imports MonacoLanguageClient (which internally uses jsonrpc 8.x from the nested v9 copy) alongside RequestType and MessageTransports (which now resolve to jsonrpc 9.x from the root v10 copy). Passing v10 class instances into a v9-based client can break LSP transport wiring at runtime — autocomplete, hover, formatting, and similar language features would silently fail.
Consider keeping vscode-languageclient at ~9.0.1 to match what monaco-languageclient expects, and instead use an npm overrides entry to patch the transitive brace-expansion vulnerability:
"overrides": {
"brace-expansion": "^2.0.2"
}Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At frontend/package.json, line 154:
<comment>Upgrading `vscode-languageclient` to 10.0.0 while `monaco-languageclient@10.6.0` pins `~9.0.1` creates a dependency fork: npm installs both v10 at the root and a nested v9.0.1 under `monaco-languageclient/node_modules/`. The frontend's `Editor.svelte` imports `MonacoLanguageClient` (which internally uses jsonrpc 8.x from the nested v9 copy) alongside `RequestType` and `MessageTransports` (which now resolve to jsonrpc 9.x from the root v10 copy). Passing v10 class instances into a v9-based client can break LSP transport wiring at runtime — autocomplete, hover, formatting, and similar language features would silently fail.
Consider keeping `vscode-languageclient` at `~9.0.1` to match what `monaco-languageclient` expects, and instead use an npm `overrides` entry to patch the transitive `brace-expansion` vulnerability:
```json
"overrides": {
"brace-expansion": "^2.0.2"
}
```</comment>
<file context>
@@ -151,7 +151,7 @@
"unist-util-visit": "^5.0.0",
"vscode": "npm:@codingame/monaco-vscode-extension-api@=25.0.0",
- "vscode-languageclient": "~9.0.1",
+ "vscode-languageclient": "~10.0.0",
"vscode-uri": "~3.1.0",
"vscode-ws-jsonrpc": "~3.5.0",
</file context>
| "vscode-languageclient": "~10.0.0", | |
| "vscode-languageclient": "~9.0.1", |
| "unist-util-visit": "^5.0.0", | ||
| "vscode": "npm:@codingame/monaco-vscode-extension-api@=25.0.0", | ||
| "vscode-languageclient": "~9.0.1", | ||
| "vscode-languageclient": "^10.0.0", |
There was a problem hiding this comment.
P2: Version specifier mismatch: package.json declares ~10.0.0 (tilde — only patch updates) but package-lock.json records ^10.0.0 (caret — minor + patch updates) for the same dependency. This inconsistency means a clean npm install may produce a different lockfile, causing CI/CD or teammate reproducibility issues.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At frontend/package-lock.json, line 79:
<comment>Version specifier mismatch: `package.json` declares `~10.0.0` (tilde — only patch updates) but `package-lock.json` records `^10.0.0` (caret — minor + patch updates) for the same dependency. This inconsistency means a clean `npm install` may produce a different lockfile, causing CI/CD or teammate reproducibility issues.</comment>
<file context>
@@ -76,7 +76,7 @@
"unist-util-visit": "^5.0.0",
"vscode": "npm:@codingame/monaco-vscode-extension-api@=25.0.0",
- "vscode-languageclient": "~9.0.1",
+ "vscode-languageclient": "^10.0.0",
"vscode-uri": "~3.1.0",
"vscode-ws-jsonrpc": "~3.5.0",
</file context>
| "vscode-languageclient": "^10.0.0", | |
| "vscode-languageclient": "~10.0.0", |
2 participants
Snyk has created this PR to fix 1 vulnerabilities in the npm dependencies of this project.
Snyk changed the following file(s):
frontend/package.jsonfrontend/package-lock.jsonVulnerabilities that will be fixed with an upgrade:
SNYK-JS-BRACEEXPANSION-17706650
Breaking Change Risk
Important
Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic
Learn how to fix vulnerabilities with free interactive lessons:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.
Summary by cubic
Upgrade
vscode-languageclientfrom 9.0.1 to 10.0.0 to resolve a transitivebrace-expansionvulnerability and keep the language client stack current. This updates the lockfile and raises engine requirements.Dependencies
vscode-languageclientto~10.0.0infrontend/package.json.semver7.8.x,minimatch10.x, andvscode-languageserver-textdocument; protocol moved to 3.18.0.Migration
minimatch/brace-expansion.vscode-languageclient10 targetsvscode^1.91.0. Verify compatibility with@codingame/monaco-vscode-extension-api.Written for commit 3607ff1. Summary will update on new commits.