Is VS Code v1.110.0 a necessary requirement?

[grantmcdermott]

Question for you @randy3k:

Throughout the work on 3.0.0, I must confess that I hadn't really noticed that the extension requires VS Code 1.110 or later.

Unfortunately, this is now blocking me at work. We run OpenVSCode Server (not my preferred choice, but a bigger engineering challenge than I'm able to fight rn), and the newest version available to us is 1.103.1. Changing platforms isn't a realistic option in the short term, so I'm stuck on vscode-R 2.8.x :'-(

AFAICT, this requirement came in with the session watcher rewrite in 4e1ca8b (#1684). I couldn't find a stated reason for the bump in the commit, the PR or the changelog. At the same time, I don't think that vscode-R 3.0.0+ actually uses any API newer than 1.75? I asked Claude to investigate and it agreed, pointing out that @types/vscode is still pinned at ^1.75.0, so any newer API would fail to type-check.

Was 1.110 chosen for a specific reason (a runtime behavior, a webview or terminal feature, or similar), or was it simply the current release at the time? If it's the latter, could we entertain a PR that lowers the minimum (for example to ^1.75.0 or ^1.100.0)?

I'm happy to test 3.x on 1.103.1 and report back.

[randy3k]

I don't recall why it was upgraded to be honest, please test downgrading it. I am sure more users will have the same question.

[Vituartzz]

I went through 3.0.1 to back up your reading. I couldn't find anything that needs more than 1.75, so 1.103.1 should be fine.

• Types. package-lock.json resolves @types/vscode to exactly 1.75.0 (not just ^1.75.0), so every typed vscode.* call type-checks against the 1.75 API.
• No escape hatches. There's no @ts-ignore/@ts-expect-error and no as any cast on vscode anywhere in src/, and package.json has no enabledApiProposals.
• Contribution points. terminal, viewsContainers, views, viewsWelcome, languages, snippets, grammars, commands, keybindings, menus, submenus, configuration, configurationDefaults, taskDefinitions and problemMatchers all predate 1.75.
• Runtime. The new session watcher from 4e1ca8b uses net.createServer plus JSON-RPC (no ws, no global WebSocket), fetch comes from node-fetch, and the TS target is ES2022. Nothing there needs a newer extension-host Node than 1.103 ships.

The bump itself is just "vscode": "^1.75.0" → "^1.110.0" in that commit's package.json, next to the version change to 3.0.0-rc.0.

To test on OpenVSCode Server 1.103.1 without waiting for a release:

1. Download r-3.0.1.vsix from the v3.0.1 GitHub release.
2. It's a zip: change extension/package.json to "engines": { "vscode": "^1.103.0" } and zip it back with the same layout.
3. Run openvscode-server --install-extension r-3.0.1.vsix, then exercise attach / the session watcher, plots and help.

If that holds up, a PR that lowers engines.vscode (back to ^1.75.0, or to the oldest version you actually tested) is the fix @randy3k suggested.

[renkun-ken]

I checked the runtime dependencies and ran compatibility checks on VS Code 1.82.0. My recommendation is ^1.82.0 for both vscode-R and R Syntax, rather than returning to ^1.75.0.

Two constraints are missing from the type-definition argument:

• vscode-languageclient 9.0.1 requires VS Code 1.82.0 and explicitly throws below that version. The check is present in the published R 3.0.1 bundle: upstream runtime check. Pinning this extension’s @types/vscode to 1.75 does not cover bundled dependencies’ runtime requirements.
• R Syntax currently declares ^1.90.0, but that is not an inherent runtime requirement. It contains only language configurations and TextMate grammars, with no executable entry point or runtime dependencies. Its newest required feature appears to be region folding, introduced in VS Code 1.17. That 1.17 floor is source-derived; I did not run the complete 1.17 application.

With the manifest constraints lowered, these checks passed on an isolated VS Code 1.82.0 on macOS:

• Published R 3.0.1 VSIX: activation, registration of 110 R commands, session-watcher initialization, R language hover, and data-grid rendering, sorting, filtering, floating filters, column sizing and reset.
• R Syntax, tested separately: region folding, automatic brackets, R comments, and R Markdown comments that switch correctly between embedded R and Markdown.

I found no requirement for 1.110. These were targeted compatibility checks, not a complete regression run. Lowering both extensions to ^1.82.0 would provide a tested baseline; leaving R Syntax at ^1.90.0 would still block installations below 1.90.

OpenVSCode Server 1.103.1 exceeds both existing dependency requirements, so lowering just the R extension’s manifest should allow testing there. That specific server environment still needs the attach/session, plot and help checks suggested above.

[renkun-ken]

Update to my earlier compatibility finding: PR #1831 upgrades the client to vscode-languageclient 10.1.2. The published package enforces VS Code 1.91.0, replacing client 9.0.1's 1.82.0 floor. R Syntax 0.1.4 requires 1.90.0, so OpenVSCode Server 1.103.1 exceeds both dependency requirements. vscode-R's manifest still declares 1.110.0 and still blocks installation there.

With only the manifest temporarily lowered, the upgraded extension passed TCP and stdio checks for completion, signature help, multiple-range formatting, diagnostics after edits, and shutdown on VS Code 1.91.0 / bundled Node 20.9.0, with R languageserver 0.3.20. It also type-checks against the 1.91 API. However, a broader 1.91 run encountered repeated Interactive timeouts and was stopped, so this establishes the language-client floor rather than complete extension compatibility. Lowering the supported manifest baseline needs a separate validated change, including checks on the actual OpenVSCode Server environment.

The published-package evidence and test details are in this PR comment.

[renkun-ken]

Follow-up with full-suite results: I recommend VS Code 1.94.0 (engines.vscode: "^1.94.0") as the minimum for the current vscode-R code plus the vscode-languageclient 10.1.2 upgrade in PR #1831.

On macOS arm64, 1.94.0 passed all 391 extension tests and both separate installer tests twice, including a final run with normal timeouts, no bail, no retries, no test changes and no skips. It uses bundled Node 20.16.0; the actual host-runtime launch test also passed. The other current checks passed, including 116 Node tests and 1,246 sess R assertions, and the source plus dependency declarations type-check against the actual 1.94 API.

I tested every published VS Code release from the language client's 1.91.0 floor through 1.93.1. Each failed the full run at the Interactive test that waits for the stopped-session notebook notice after q("no"). A focused 1.91.1 run passed that test alone, so this is the minimum established by the current full suite, not proof of an inherent 1.94 API requirement. Client 10.1.2 itself still enforces only 1.91.0.

VS Code desktop 1.103.1 also passed all 393 VS Code tests, so the results support lowering the current 1.110.0 manifest requirement. OpenVSCode Server 1.103.1 exceeds both the recommended 1.94.0 baseline and R Syntax's declared 1.90.0 minimum. These runs were on macOS desktop; the actual OpenVSCode Server environment and a 1.94.0 Linux/Windows matrix still need validation.

The manifest remains 1.110.0 in the upgrade PR; 1.94.0 is the recommendation from this investigation. Detailed version-by-version evidence.

[renkun-ken]

#1832 sets VS Code 1.94.0 (engines.vscode: "^1.94.0") as the minimum required vscode version.

[grantmcdermott]

Thanks @renkun-ken!

(I was slammed at work and didn't have a chance to test thoroughly myself, so appreciate you taking it up.)

[eitsupi]

I want to bump to 1.101.0.
See #1850

[grantmcdermott]

Okay, with me. But could you add more context about what the Node + Electron bump buy us?

[eitsupi]

Node 20 has already reached its End of Life, and continuing to support it would hinder the updating of dependency packages.