fix: --inspect to work inside workers

[AriPerkkio]

• Fixes Cannot Debug Test Files with --inspect-brk Flag #1867

This solution doesn't utilize NodeJS CLI arguments --inspect or --inspect-brk, but mimics how they work.
We can only open inspector in a single worker_thread or child_process at a time so threads: false or singleThread: true is required. IDEs may do their own magic which allows debugging multiple worker_threads, e.g. VSCode's autoAttachChildProcesses.

When these flags are used, it's not possible to debug the main thread. But Vitest users should never need to do that, right?

Minimal demo for testing inspector with worker_threads and child_process: https://gist.github.com/AriPerkkio/ffd517437c50e64ccdc875b5e3553089

[alexlafroscia]

One thing I'm thinking about, in terms of these --inspect and --inspect-brk looking like the normal flags but not actually being passed down to child processes... is there a risk that users might be confused by that at all?

I occurs to me that the flag could really be called anything -- it could be something like

vitest --debug

or something like that, with this same behavior, but without any mental baggage that folks might bring along with seeing --inspect or --inspect-brk.

I definitely don't think it's a major risk or anything, and am really happy to see this change land! It just feels like it could be a little confusing. Using something like --debug for this test-debugging situation also means that the original --inspect behaviors could be maintained, if that was desirable.

[AriPerkkio]

these --inspect and --inspect-brk looking like the normal flags but not actually being passed down to child processes

The --inspect and --inspect-brk CLI flags could be used instead of utilizing node:inspector directly but it does not work for worker_threads. It works fine for child_process though. So for interoperability I think it's better to choose one way and use it in both cases.

This works fine:

import { fork } from "node:child_process";
import { fileURLToPath } from "node:url";

const filename = fileURLToPath(import.meta.url);

if (!process.env.CHILD_PROCESS) {
  fork(filename, { execArgv: ["--inspect-brk"], env: { CHILD_PROCESS: "true" }, });
} else {
  debugger; // Stops in child_process
}

This does not work:

import { isMainThread, Worker } from "node:worker_threads";
import { fileURLToPath } from "node:url";

const filename = fileURLToPath(import.meta.url);

if (isMainThread) {
  new Worker(filename, { execArgv: ["--inspect-brk"] });
} else {
    debugger; // No stop here
}

But if node:inspector is used inside worker_threads it works just fine. To me this looks like a bug or missing feature of NodeJS.

import { isMainThread, Worker } from "node:worker_threads";
import { fileURLToPath } from "node:url";
+import inspector from "node:inspector";

const filename = fileURLToPath(import.meta.url);

if (isMainThread) {
  new Worker(filename, { execArgv: ["--inspect-brk"] });
} else {
+  if (process.execArgv.includes("--inspect-brk")) {
+    inspector.open();
+    inspector.waitForDebugger();
+  }

  debugger; // Stops in worker thread!
}

We could rename these options to --debug but I would rather use the names of existing options. I've checked the NodeJS sources and I cannot spot anything else that these options would do. The internal inspector APIs are a bit different but in the end it should work the same way.

[alexlafroscia]

Thanks for such a detailed explanation, @AriPerkkio! That sounds reasonable to me