V8 Inspector is not available in --require in `node --test`

[connor4312]

Version

v20.3.0

Platform

Darwin MacBook-Pro-2.local 22.5.0 Darwin Kernel Version 22.5.0: Mon Apr 24 20:51:50 PDT 2023; root:xnu-8796.121.2~5/RELEASE_X86_64 x86_64

Subsystem

test_runner

What steps will reproduce the bug?

1. Have a file start-inspect.js containing:

const inspector = require("node:inspector");
inspector.open();

2. Have some other file.test.js, which can be empty.
3. Run NODE_OPTIONS="--require ./start-inspect.js" node --test ./hello.test.js

How often does it reproduce? Is there a required condition?

100%

What is the expected behavior? Why is that the expected behavior?

The inspector should open as usual, as if --test was not given in the CLI

What do you see instead?

$ NODE_OPTIONS="--require ./start-inspect.js" node --test ./hello.test.js

node:inspector:181
  open(port, host);
  ^
This Environment was initialized without a V8::Inspector
(Use `node --trace-uncaught ...` to show where the exception was thrown)

Node.js v20.3.0

Additional information

This does not happen if --test is omitted from the command. This causes issues with the VS/Code debugger which uses this mechanism to initiate debugging. I think Jetbrains does the same thing, so Webstorm and friends probably have the same issue, though I have not tested it.

Also, if I try to open the inspector in the test file itself, it works fine, so it seems like there might be some initialization ordering that's different for --test.

Originally reported on microsoft/vscode-js-debug#1727

[MoLow]

I think this is because the code is trying to access the inspector both in the parent (orchestrator) process, and in the child process.
I guess we should provide a way to determine whether you are inside a test file or not. @cjihrig WDYT?

Edit:
On second thought, This is expected to fail on the parent process, and can be handled with a simple try/catch.
if you really need to know you are now in the main process you can look at the NODE_TEST_CONTEXT environment variable

please LMK if this helps you.

[cjihrig]

I think we may want to look into skipping preloads in the test runner main process, but still propagating the preload flags to the child processes. I can't think of a good reason why preloads need to run for the main process.

[rluvaton]

Tested and had the same problem in webstorm as well

[damianobarbati]

Any news on this? I also have the debugger broken in webstorm when using tsx :(