[eitsupi]

Motivation

Two Dependabot alerts cannot be fixed automatically:

• @azure/msal-node GHSA-xcx6-jx8p-x3h5 (fixed in 7.1.0), pulled in by @vscode/vsce and ovsx through @azure/identity@4.13.3.
• minimatch GHSA-g3hv-75wg-m249 (affects >=7.0.0 <11.0.1, no fixed 10.x release).

Changes

• Update @azure/identity in the lockfile to 4.14.1. It depends on @azure/msal-node ^7.1.0, so @azure/msal-node is now 7.2.1. This fixes the msal-node alert without changing any version range in package.json.
• Update @vscode/vsce from ^3.6.0 to ^4.1.0. ovsx@1.3.0 already depends on vsce 4, so two vsce trees were installed. vsce 4 needs Node.js 22 or later (CI uses 24). It replaces glob with tinyglobby and no longer depends on keytar, so keytar is removed from allowBuilds. The lockfile loses about 1,000 lines.
• Remove src/test/suite/index.ts. It is the old Mocha runner from before @vscode/test-cli, and .vscode-test.mjs does not use it. The root glob dev dependency was only used there, so it is removed too.
• TypeScript 7 defaults types to []. The removed runner's import Mocha from 'mocha' was what loaded the Mocha globals (suite, test) for the other test files, so tsconfig.json now lists mocha and node in types.

No CHANGELOG entry, as this is an internal change.

Notes: minimatch alert stays open

This PR does not fix the minimatch alert, and it cannot be fixed with an overrides entry:

• vscode-languageclient (10.1.2, and also the latest 11.0.0) depends on minimatch ^10.2.6 and calls Minimatch#makeRe(). minimatch 11 removes makeRe(), so forcing 11 would throw a TypeError at runtime in the bundled extension. Upstream tracks this in microsoft/vscode-languageserver-node#1938 (the fix PR microsoft/vscode-languageserver-node#1935 currently fails CI).
• glob 10 and 13 (via mocha, @vscode/test-cli and test-exclude) need glob 14 for minimatch 11, so the dev tools would need several more overrides. The alert would still stay open because of vscode-languageclient.

The vulnerable code (firstPhasePreProcess) only runs with optimizationLevel >= 2. vscode-languageclient uses the default level 1, and its patterns come from the R language server. glob uses level 2, but only with the repository's own test globs. Once vscode-languageclient releases a version on minimatch 11, the alert should be fixable with a normal update.

Update: debugging extension tests

The Extension Tests launch configuration in .vscode/launch.json still pointed at the removed runner (out/test/suite/index), so it could no longer run any tests. It now uses js-debug's testConfiguration option (VS Code 1.87+) with .vscode-test.mjs:

• After the pretest pre-launch task, js-debug runs vscode-test --list-configuration, asks which configuration to run, and launches @vscode/test-cli's own runner with that configuration's files, Mocha options and launch arguments. F5 debugging works as before, without a second hand-written runner or the glob dependency.
• This is also more accurate than the old runner, which ran every src/test/suite/ file in one window without out/test/common/extensionSetup.js or the per-suite profiles.
• Unlike the CLI, it runs in the current VS Code and does not install extension dependencies, so R Syntax must already be installed. CONTRIBUTING.md says this.

Extension Test Runner (ms-vscode.extension-test-runner) is added to the workspace recommendations as an optional way to run or debug individual tests from the Testing view. Neither the debugger nor the CLI requires it.

The sess-install-tasks configuration is removed. Its only test (src/test/integration/sessInstall.test.ts) was removed in #1856, so it ran 0 tests. Its temporary workspace was also deleted on process exit, so it was gone when a separate --list-configuration process (as used by the debugger and Extension Test Runner) exited.

Update: working-directory-independent test profiles

Test profile directories in .vscode-test.mjs now resolve relative to the configuration file's import.meta.url, using fileURLToPath for native filesystem paths. js-debug can load the configuration from a working directory outside the checkout, including the VS Code installation directory on Windows. Profiles now consistently stay under the checkout's .vscode-test/user-data directory.

[renkun-ken]

The dependency cleanup looks consistent: the production dependency graph is unchanged, the MSAL version is patched, and the existing packaging/publishing interfaces remain compatible with vsce 4. I found one regression in the documented Extension Tests debugger workflow that should be fixed before merging; see the inline comment.

Validation on 01f211c: a fresh frozen-lockfile install, typecheck, lint, format:check, pretest, vsce package --no-dependencies, and the packaged sess identity check all pass locally. After that successful pretest, resolving the test runner configured in .vscode/launch.json fails with MODULE_NOT_FOUND. All six hosted CI checks are green; those use the CLI runner and do not exercise this debug configuration.

[renkun-ken]

The testConfiguration migration addresses my previous missing-runner finding. Removing the empty sess-install-tasks configuration is also consistent with the current tree, and the contributor instructions match the new workflow. I found one remaining problem in the F5 integration: loading the configuration from the debugger's inherited working directory can fail while creating test profiles; see the inline comment.

Validation on 8f80914: typecheck, lint, format:check and pretest pass locally. --list-configuration from the checkout resolves all 50 extension test files exactly once (47 provider, 2 editor-command, 1 Interactive), with valid CLI runner, Mocha setup and profiles. I traced the installed js-debug resolver and VS Code Windows bootstrap, then reproduced EACCES by loading this exact configuration from a read-only external working directory. All six hosted CI checks are green, but those invoke the CLI from the checkout and do not cover this F5 configuration-loading context.

[renkun-ken]

Both previous findings are addressed: Extension Tests uses the supported testConfiguration integration, and test profiles now resolve from the configuration file's URL rather than the debugger's working directory. No further actionable findings.

Verified on 2d46cbb: configuration loading now succeeds from a read-only external working directory, creates no files there, and uses the same checkout profiles as invocation from the repository. All 50 extension test files are discovered exactly once (47 provider, 2 editor-command, 1 Interactive), with valid CLI runner and Mocha setup. JavaScript syntax validation passes, and Windows file-URL conversion handles spaces and special characters correctly. All six hosted CI checks are green.