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.