Method to run Node test-runner ignoring/rejecting any `test.only`/`test(..., { only: true }, ...` filters

What is the problem this feature will solve?

Since the resolution of #47945, node --test will automatically filter tests which are not marked .only, if

• any test/suite is marked with only: true
• AND
  • --test-only is passed a command line flag
  • OR process-isolation is disabled by --test-isolation=none

In addition, since #51383, filtered tests/suites are not passed to test-reporters at all.

When developing locally, this is convenient. However, when running tests in CI, it means there is no way to detect whether or not test-filtering is occurring when --test-isolation=none. This means it's possible for someone to accidentally push a.only call, which will silently disable the rest of the tests.

It appears that this logic is defined here:

• 24 (current LTS): https://github.com/nodejs/node/blob/v24.x/lib/internal/test_runner/harness.js#L47
• current main: https://github.com/nodejs/node/blame/f9f343fb8dda773b749db4dee00704f8bbe79c19/lib/internal/test_runner/harness.js#L47

which forces isFilteringByOnly to be true when globalOptions.isolation === 'process' || process.env.NODE_TEST_CONTEXT is false (note that this presents a partial workaround for Node 24, but not Node 22 which is still supported until April 2027)

What is the feature you are proposing to solve the problem?

A command-line option that allows running tests in a way that detects accidental inclusions of { only: true } / it.only / describe.only / etc.

additional --test-only flag features

I think the simplest & best option would be to introduce 2 new possible values for the --test-only flag:

• --test-only / --test-only=true: The current behavior
• --test-only=false:
  • Runs all tests; even if some other tests are marked with { only: true }, tests are NOT filtered out for having { only: false }.
  • Other filtering (from name patterns) still occurs as normal.
• --test-only=error:
  • I think there are several reasonable semantics for this mode, which I don't have strong opinions between:
    • Should it generate an error...
      • ...when the tests are collected?
      • ...when the tests are run?
      • ...after the tests are run?
    • Should it report an error...
      • ....if any test/suite specified { only: true }?
      • ...if a test is filtered because it didn't specify { only: true }?
      • (The difference is only in test-suites that mark EVERY test as .only so the difference is probably negligible)
    • Should it run the tests as normal?
      • Should it report an error for filtered/only tests in the stead of that test?
      • Or should it report a separate "sub test" regarding the unexpected use of only?
      • Should it report the unexpected use of only overall (either before/after running all tests) or only at the end/beginning as a count of filtered tests only?

additional test-reporter events

While I think --test-only=error's behavior would generally be desirable to essentially all Node programs using the node:test runner when running tests in CI, configuration for it in different test-reporters may become complicated over time.

A more customizable alternative would be to emit an additional event for filtered tests, which indicates what caused the test to be filtered. Handling of this event could be added to either custom-reporters, a new build-in test-reporter, or the existing test-reporters, to emit an error in the case that filtered test-cases are undesirable.

What alternatives have you considered?

From reading the documentation of test runners and the command-line arguments, it seems the current version of Node does not have a way to cause this kind of behavior when running the test runner via the node --test CLI.

Because filtered tests do not emit events to test-reporters (#51383), a custom test-reporter cannot be used to detect this.

I can see several ways to workaround this right now:

lint against .only / { only: true } invocations of node:test

This is probably the most straightforward, but it is very complex, and cannot be complete. It cannot detect non-textual references to these, for example, in the (admittedly undesirable) case these flags are computed dynamically, or tests are imported from another library.

(Node 24+) use the undocumented NODE_TEST_CONTEXT=_ workaround

It seems this parameter is used for process-isolation; however, when not using process-isolation, it also triggers the branch that allows the isFilteringByOnly to default to false/undefined in Node 24+.

This seems likely unintentional and the behavior is documented to be unpredictable

This workaround does not support the --test-only=error use case.

enable test-isolation

Enabling process isolation for tests will effectively disable the { only: true } filtering logic

This workaround does not support the --test-only=error use case.

introduce a "canary" test to detect filtering

To ensure tests aren't filtered, I can introduce a dummy test("ensure not filtered", () => {}); and ensure that this test is reported.

This mostly works, but it is indirect and incomplete. For example, if a .only call is added to the canary test, any .only calls become allowed anywhere else.

manually construct run tests instead of using the node --test CLI

While the CLI does not seem to currently support the proposed --test-only=false flag, the run method exposed in node:test does:

// Only seems to work in Node 22?
import nodeTest from "node:test";
import { spec } from "node:test/reporters";

nodeTest
  .run({
    concurrency: false,
    globPatterns: ["dist/**/*.spec.js"],
    isolation: "none",
    coverage: false,
    /** Milliseconds */
    timeout: 90_000,
  })
  .compose(spec)
  .pipe(process.stdout);

This workaround does not appear to support the --test-only=error use case, although it may be possible

Empieza por lib/internal/test_runner/harness.js, especialmente por la lógica isFilteringByOnly descrita en el issue, y compárala con el comportamiento de la CLI --test-only y las opciones de run() de node:test. Primero resuelve la semántica prevista para false y error, incluidos el reporting y los eventos del reporter; se considera terminado cuando el comportamiento y las pruebas de aceptación estén acordados e implementados para las versiones de Node compatibles.