Debugging Browser Tests doesn't work in project setups

[Alanoll]

Describe the bug

I'm having an issue debugging into a test when run in browser mode and my projects are setup using projects.

The test runs, and reports a success result, but never breaks into the debugger. I eventually after a timeout recieve an error saying Cannot connect to the target at localhost:9229: Could not connect to debug target at http://localhost:9229: Could not find debuggable target from VSCode.

This may be related to #689 as it's workspace/project related, but didn't report anything about debugging.

Reproduction

I've narrowed it down to something to do with the Vitest Project setup.

https://github.com/Alanoll/vitest-vscode-project-repro

The repo currently triggers the bug.
If you modify the vite.config.mts at the root and comment line 40, it will use a non-project configuration and work.

Output

[INFO 10:03:57 PM] [API] Resolving configs: vitest-repro/vite.config.mts
[INFO 10:03:57 PM] [API] Running Vitest v4.0.14 (vitest-repro/vite.config.mts) with "C:\Program Files\nodejs\node.EXE C:/Users/***/.vscode/extensions/vitest.explorer-1.34.0/dist/worker.js"
[INFO 10:03:57 PM] [API] Watching vite.config.mts
[INFO 10:03:57 PM] [VSCODE] Watching vitest-repro with pattern **/*
[10:03:57 PM] [VSCODE] Ignoring file: node_modules\.vite-temp\vite.config.mts.timestamp-1764475437624-87ff322675c9a.mjs
[10:03:57 PM] [VSCODE] File deleted: node_modules\.vite-temp\vite.config.mts.timestamp-1764475437624-87ff322675c9a.mjs
[INFO 10:03:57 PM] [API] Collecting tests: projects/project1/src/math.test.ts [project1 (chromium)]
[INFO 10:04:17 PM] [DEBUG] Starting debugging session C:\Program Files\nodejs\node.EXE
[INFO 10:04:18 PM] [DEBUG] Debugging started
[10:04:18 PM] [VSCODE] Ignoring file: node_modules\.vite-temp\vite.config.mts.timestamp-1764475458653-cbf064c83e3b1.mjs
[INFO 10:04:18 PM] Running 1 file(s) with name pattern: ^\s?addition add$
[10:04:18 PM] Starting a test run because projects/project1/src/math.test.ts triggered a watch rerun event
[10:04:18 PM] Enqueuing "add"
[10:04:19 PM] [VSCODE] File deleted: node_modules\.vite-temp\vite.config.mts.timestamp-1764475458653-cbf064c83e3b1.mjs
[10:04:19 PM] No task result for "math.test.ts [project1 (chromium)]", ignoring
[10:04:19 PM] No task result for "addition", ignoring
[10:04:19 PM] Enqueuing "add" because it was just collected
[10:04:19 PM] Ignore "sum" during collection
[10:04:19 PM] Ignore "skipped" during collection
[10:04:19 PM] Ignore "todo" during collection
[10:04:19 PM] Ignore "async task" during collection
[10:04:19 PM] Ignore "async task 0.5s" during collection
[10:04:19 PM] Ignore "async task 1s" during collection
[10:04:19 PM] Ignore "long task" during collection
[10:04:19 PM] No errors found for "math.test.ts [project1 (chromium)]"
[10:04:19 PM] No errors found for "addition"
[10:04:19 PM] Marking "add" as passed
[10:04:19 PM] Marking "sum" as skipped
[10:04:19 PM] Marking "skipped" as skipped
[10:04:19 PM] Marking "todo" as skipped
[10:04:19 PM] Marking "async task" as skipped
[10:04:19 PM] Marking "async task 0.5s" as skipped
[10:04:19 PM] Marking "async task 1s" as skipped
[10:04:19 PM] Marking "long task" as skipped
[10:04:19 PM] No errors found for "math.test.ts [project1 (chromium)]"
[10:04:19 PM] Ending test run projects/project1/src/math.test.ts
[10:04:19 PM] Test run promise is finished, the queue is 0
[10:04:19 PM] [API] Vitest WebSocket connection closed, cannot call RPC anymore.
[10:04:19 PM] Ending test run <none>
[10:04:19 PM] Disposing test runner
[10:04:19 PM] Ending test run <none>
[10:04:19 PM] [VSCODE] Ignoring file: node_modules\.vite\vitest\da39a3ee5e6b4b0d3255bfef95601890afd80709\results.json

Extension Version

1.34.0

Vitest Version

4.0.14

Validations

• Check that you are using the latest version of the extension
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[Alanoll]

Digging into this a bit more, it seems like the extension never got fully updated for Vitest v4's breaking change of Workspaces => Projects?

[Alanoll]

I tried to debug a bit into this some more, but I'm just not familiar with the codebase enough. Any thoughts @sheremet-va ?

[Alanoll]

I think I may have tracked the why it's not working (at least the next stop in the chain). I could be completely misinterpreting though.

The Extension using an inline vite plugin to pass the debugger/inspector options in to vitest :

vscode/packages/worker/src/index.ts

Line 125 in 1eaddb5

configureVitest(context) {

When not using the projects style configuration, the method configureVitest is called during initialization. When using projects, this method is never called, and therefore the options are never passed vitest.

I don't think this inline plugin is getting passed to the calls internally in vitest to resolve the per project configuration blobs. Should it? or is using configureVitest the wrong place to attempt to configure the inspector?

[npbenjohnson]

I found a non-spec workaround. It seems there is probably a config merge/inheritance issue with the vscode extention vs running directly with vitest.

This example is for external vitest config files, but this appears to work for multiple projects in one file also.
I don't believe it is possible to combine the 2 into a root project that references config which contains projects instead of a test, because it results in another bunch of issues with things like browser/plugin/alias not loading from the deepest child config.

import { defineConfig } from "vitest/config";
import { url } from "node:inspector";
const isDebugSession = Boolean(url());
/**
 * PackageNote: vitest@4.0.15 vitestExt:1.36.0
 * This should be defineProject, but vscode extension requires inspectBrk,
 * fileParallelism, and cache to be defined at top level to work consistently.
 */
export default defineConfig({
  test: {
    cache: false, // PackageNote: vitest@4.0.15 Makes vscode plugin work more consistently
    // /*
    // PackageNote: vitest@4.0.15
    // Vscode plugin run/debug only works if inspectBrk and fileParallelism are set in a parent
    // level above projects specs, even if there is only one project
    // */
    inspectBrk: isDebugSession,
    fileParallelism: !isDebugSession,
    projects: ["packages/*/vitest{.*.,.}config.ts"],
  },
});

Not sure if these are relevant, but here are my extension settings just in case:
Note: changing --configLoader=runner breaks extension until a full vscode restart

  "vitest.rootConfig": "vitest.config.ts", // Just in case, make sure this resolves vitest instead of vite
  "vitest.configSearchPatternInclude": "",
  "vitest.cliArguments": "--configLoader=runner",

[Alanoll]

So it looks like the issue is that the way the vscode extension is attempting to enable the inspector flags doesn't work for projects, because the inline vitest plugin that it uses to set the options is never passed down the chain.

The fix for this is to somehow manually inspector options within the config file (until a fix in the extension is made). @npbenjohnson achieves with his config level changes. I would probably use inspect instead of inspectBrk so that the debugger don't break on the first line of code executed :)

I made a quick fork of the extension to use myself with the following change: bc6ec31

I don't mind submitted a PR to get this added to the repo, but that's @sheremet-va 's call. The change doesn't seem worse then what the custom plugin does.

[sheremet-va]

I made a quick fork of the extension to use myself with the following change: bc6ec31

This is not the only change that's strictly required, the browser setup file should also be injected to be consistent. I think adding the configureVitest code to the reporter's onInit (similar to ensureSetupFileIsAllowed) is better

[Alanoll]

@sheremet-va I've added the code for the browser setup file to the reporter onInit. In my brief testing, it wasn't honoring setting the inspector options there, but it did respect the setupFile changes.

I've submitted a PR to the repo for review.