Setting `"experimental-test-coverage": true` within node.config.json causes multiple reports

[JakobJingleheimer]

Version

24.3.0

Platform

Subsystem

No response

What steps will reproduce the bug?

1. Create a node.config.json file and include "experimental-test-coverage": true
2. in CLI, run node --experimental-config-file='./node.config.json' --test

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

100%

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

It behaves like passing the CLI flag --experimental-test-coverage.

What do you see instead?

It appears the test coverage "flag" from the config file is getting passed along to the various sub-processes the test runner spawns, and they are each reporting their own set of tests' coverage. And then at the end, the parent process reports the full coverage.

Additional information

Merely moving the test coverage flag from config file to cli (leaving other options in the config file) avoids the issue.

node.config.test.json

{
  "$schema": "https://nodejs.org/dist/v24.3.0/docs/node-config-schema.json",
  "nodeOptions": {
    "import": [
      "../../test/snapshots.mts"
    ]
  },
  "testRunner": {
    "experimental-test-coverage": true,
    "experimental-test-module-mocks": true,
    "test-coverage-exclude": [
      "**/test/**",
      "**/*.mock.ts",
      "**/*.test.ts"
    ]
  }
}

[JakobJingleheimer]

Test runner is filtering the options passed to child_process https://github.com/nodejs/node/blob/main/lib/internal/test_runner/runner.js#L101 (thanks @pmarchini for the investigation).

But I believe cp reads from process.env (or whatever that is derived from), which means the filtered out options are resurrected by cp when spawning, effectively ignoring test runner's filtering. So the filtering would instead need to be (conditionally) applied wherever cp is doing this.

I'll try to take a look in the next few days.

[marco-ippolito]

can you provide an example of your node.config.json

[JakobJingleheimer]

Added to the OP (so it doesn't get buried) under a <details>.