fix(ci): upgrade @vscode/test-electron to fix macOS test failures

[wenytang-ms]

Problem

This repo is not red yet, but only because its last macOS run predates the VS Code 1.131.0 release. The identical failure is already reproducing in sibling repos — vscode-java-test, vscode-java-dependency, vscode-spring-boot-dashboard — each with the same signature:

Test error: Error: spawn .../.vscode-test/vscode-darwin-arm64-1.131.0/Visual Studio Code.app/Contents/MacOS/Electron ENOENT
Error: Test run failed with code -2

This repo downloads VS Code unpinned (so it resolves 1.131.0) and is on an affected @vscode/test-electron, so its next macOS run will fail the same way. This is a pre-emptive fix.

Root cause

VS Code 1.110 renamed the macOS main binary inside the .app bundle from the historical Electron to the product name (Code), keeping a compatibility symlink under the old name. That symlink was removed in microsoft/vscode#326502, so any 1.110+ archive now fails to launch via the old path. The test runner does not pin a VS Code version, so it resolves the latest release (1.131.0) and hits this.

@vscode/test-electron ^2.4.1 hardcodes the old path in out/util.js:

return path.resolve(dir, 'Visual Studio Code.app/Contents/MacOS/Electron');

Only macOS goes through this code path, which is why the other platforms are unaffected. Upstream fixed it in microsoft/vscode-test#350, released in 3.1.0: the executable is resolved from CFBundleExecutable in Info.plist, falling back to the sole regular file in Contents/MacOS/ and finally to the legacy Electron name, so both the new and pre-1.110 layouts work. The fix landed after 3.0.0, so 3.1.0 is the earliest release that carries it — there is no 2.x backport.

Changes

Bump @vscode/test-electron ^2.4.1 → ^3.1.0. package.json (+ lockfile) and one line in tsconfig.json.

Beyond @vscode/test-electron itself, the only lockfile churn is inside the ora dependency tree, which 3.x bumps from ^7 to ^8.

Why skipLibCheck

3.1.0 ships declarations using the generic Buffer<ArrayBufferLike>, which needs @types/node >= 22. This repo is on TypeScript 4.9 with older @types/node, so the upgrade alone fails to compile:

node_modules/@vscode/test-electron/out/util.d.ts(107,82): error TS2315: Type 'Buffer' is not generic.

Raising @types/node was tried first and is not viable — on vscode-java-test it kept the Buffer error and introduced unrelated breakage in src/controller/utils.ts. skipLibCheck is the standard remedy for third-party declaration mismatches, and sibling repos vscode-java-dependency and vscode-spring-boot-dashboard already enable it, so this also brings the repos in line with each other.

On engines.node

3.x declares engines.node >= 22 while CI runs Node 20, so npm ci emits:

npm warn EBADENGINE Unsupported engine
npm warn EBADENGINE   required: { node: '>=22' }
npm warn EBADENGINE   current: { node: 'v20.18.1' }

This is a warning, not an error — the install completes. Verified on Node 20.18.1 that 3.1.0 loads and resolves executable paths correctly; it uses no Node 22 only APIs and its transitive dependencies all accept >=18. A Node bump is therefore not needed to fix this and is deliberately left out to keep the change minimal.

Verification

• npm install succeeds; installed version confirmed as 3.1.0.
• tsc -p ./ --noEmit passes.
• Executable resolution verified directly against downloadDirToExecutablePath(..., "darwin-arm64") with synthetic bundles: the new layout (CFBundleExecutable=Code) resolves to Code, and the legacy Electron layout still resolves to Electron — so the fix covers the failure without regressing older VS Code versions.

The real confirmation is the macOS job in this PR's own CI run.

Related

Same fix applied across the affected Java extension repos: microsoft/vscode-gradle#1907 and the sibling PRs opened alongside this one.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.