--test-name-pattern needing to come before filenames is hostile to npm scripts

What is the problem this feature will solve?

It is common practice to set up npm scripts for testing. E.g.

{
  "test": "node --test tests/*.js more-tests/*.js"
}

However, this cannot be combined with --test-name-pattern. Attempting to do so, e.g.

npm test -- --test-name-pattern="my pattern"

will not work, because this gets translated to

node --test tests/*.js more-tests/*.js --test-name-pattern="my pattern"

which, I believe, ends up passing --test-name-pattern="my pattern" as an argument to these test files, instead of passing it as an argument to the test runner. The correct invocation is

node --test-name-pattern="my pattern" --test tests/*.js more-tests/*.js

but this is impossible to do via npm scripts, it seems. (See alternatives considered.)

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

I don't know what a good solution to this would be. Some possible ideas:

Special-case command line processing such that when --test is present, node grabs the --test-name-pattern argument for itself instead of passing it to scripts?
Introduce a new binary, e.g. node_test, which processes command-line arguments in such a way? I believe this is how most test runners behave.
Introduce a file-based customization of the test runner, including which tests to run, so that I don't have to pass the test filenames as arguments to the test runner in a way that causes this problem?
Improve npm scripts to support a better method of passing arguments in the middle of the script? (See below.)

What alternatives have you considered?

I investigated how to get npm scripts to substitute in arguments you pass to npm run into the script command, so that the translation becomes the correct one. This is a well-studied problem, and the following two Stack Overflow posts have the best answers, as far as I can tell:

None of them seem very satisfactory, unfortunately. In particular, if you want something that works cross-platform, you basically have to write a wrapper script.

As an alternative, I could continue using other test runners, which support npm scripts better.

@MoLow

@nodejs/test_runner @MoLow wdyt?

FWIW:

Introduce a file-based customization of the test runner, including which tests to run, so that I don't have to pass the test filenames as arguments to the test runner in a way that causes this problem?

You can do this using run, additionally you can pass parameters through the NODE_OPTIONS environment variable as a workaround.

I run into this all the time and if I could remove the script test:target for this use-case that would be phenomenal. Every single other test runner worth while accounts for this and has become part of my workflow that breaks in these setups.

you can pass parameters through the NODE_OPTIONS environment variable as a workaround.

--test-name-pattern and --test-skip-pattern aren't allowed in NODE_OPTIONS, would you like me to open a PR to change that?

➜  ~ node -v          
v22.1.0
➜  ~ NODE_OPTIONS="--test-name-pattern" node
node: --test-name-pattern is not allowed in NODE_OPTIONS
➜  ~ NODE_OPTIONS="--test-name-pattern=\"foo\"" node
node: --test-name-pattern= is not allowed in NODE_OPTIONS

If anyone wants to pick this up, it would involve updating the test runner's parseCommandLine() function to also consider values in process.argv. I don't think it would be difficult to implement technically, but there are a few caveats to consider:

The current behavior of only considering process.execArgv is how all Node core CLI flags work. Since this would be introducing an inconsistency, I'm not sure how well it would be received.
Node's C++ layer will continue to be unaware of any flags passed in process.argv. I think --test, --experimental-test-coverage, and --experimental-test-isolation are currently the only test runner flags used in the C++ layer. Another inconsistency to be aware of.
I don't think we would want to extend this to non-test runner flags. For example, people might expect --require or --import in process.argv to work, but they wouldn't.
I'm not sure if we would only want to do this when the CLI (--test) is being used, or any time node:test is used.

My feeling is that doing this might introduce more issues than it solves, but I wouldn't block anyone from doing it (others people might though).

@benjamingr

FWIW:
Currently, (without any changes) there are a few ways to achieve this goal (as @benjamingr previously mentioned):

run() - You can use the run function to specify patterns
NODE_OPTIONS - As of cli: allow --test-[name/skip]-pattern in NODE_OPTIONS #53001, you can use environment variables to specify patterns.

So I'm not sure if it's worth checking a whole new set of arguments when there are other ways to achieve this.

I'll throw in my 2 cents—I'm only just learning about node's testing suite, but it is definitely misleading that both --test and --test-name-pattern "do the testing". Just wasted about 2 hours realizing I could not easily solve OP's same problem before landing here. Seems like --test should be responsible for doing the testing, with the next arg being the path/pattern, and then just have --test-name-pattern=.../--test-skip-pattern=.../etc. act like modifiers on --test's default behavior. I would not expect those flags to actually "execute" the tests on their own (and hence they should not require a path/pattern arg after them). That would allow for an ideal scenario where both/many modifiers could be used (not even sure if that's possible now?):

package.json

{
  "scripts": {
    "build": "node --test tests/*.js"
  }
}

and use it like this:

npm build -- --test-name-pattern=@foo  --test-skip-pattern=@bar

No idea what the technical/practical implications of this change would be though since I'm new here, just seems like a more logical interface.

Same issue but run() is not suitable for me because I need to --import setup file before tests run

Also looks like NODE_OPTIONS not working, i do it like this:

NODE_OPTIONS="--test-name-pattern=\"Vector\"" npm run test

It becomes to:

node --import ./scripts/setup-tests.ts --test ./src/**/*.test.{ts,tsx}

I also have .npmrc with:

node-options='--import tsimp/import'

This script provide all tests run instead only matched by pattern

Does anyone know when it will be possible to put a --test-name-pattern flag after a --test flag and after files glob?

And will there be such a feature?

@p-mcgowan

@p-mcgowan awesome that you are already working on this! I ran into the same problem (but for occasionally updating snapshots with --test-update-snapshots), and my idea would have been exactly to allow providing the glob pattern as a named (instead of positional) argument. Started poking around the codebase how this could be implemented and found you already did. So, totally +1 for that idea.

@leoschweizer

@leoschweizer thanks! i ended up going with named glob instead of positional in the linked PR - it turned out to be a better option as I mentioned in the comments.

There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale Issues and PRs exempt from automated stale handling. label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.

Please mark as never-stale

Note that other test-specific flags suffer from the same issue as the OP described. For example, I may want a 'base' npm run script to run unit tests, but a second npm run script, leveraging the first one, that specifies the --test-reporter. My use case: in CI, I want to output test results in Junit XML format for easy storage / analytics / insights in my CI provider. Ideally I could do something like:

{
  "scripts": {
    "test:unit": "node --test --experimental-test-module-mocks --experimental-test-coverage --test-coverage-exclude='test/**/*' --test-coverage-exclude='scripts/**/*' 'test/unit/**/*.test.js'",
    "test:unit:xml": "npm run test:unit -- --test-reporter=junit",

  }
}

@MoLow

I think the underlying problem is that running tests should be a distinct command, e.g. node test or node-test, not an option flag. Not only does this command-as-flag approach cause numerous CLI syntax headaches, this issue being but one, it flies against the intuitive notion of an option flag. A flag, or any option for that matter, adjusts the behavior of an operation, not switch it out entirely for a different operation.

As I point out under a related issue, this distinction is exemplified in the difference between node --inspect and node inspect.

If running tests were a subcommand, options could come before or after arguments in the same way most other subcommand-based CLI's allow:

node test --reporter=tap tests/*.js more-tests/*.js --filter="my pattern"

Note the additional benefit: shorter and better-named options.

Passing arguments through to tests could also follow existing subcommand-based CLI conventions:

node test tests/*.js more-tests/*.js --filter="my pattern" -- "these args passed to the tests" -k

There are ways to intelligently deal with the backward compatibility concerns of introducing a node test subcommand. Note we already have node inspect. Alternatively, a separate node-test executable would give the same benefits, without any backward compatibility issues at all.

Navigation Menu

Repository navigation

--test-name-pattern needing to come before filenames is hostile to npm scripts #51384

What is the problem this feature will solve?

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

What alternatives have you considered?

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

--test-name-pattern needing to come before filenames is hostile to npm scripts #51384

Description

What is the problem this feature will solve?

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

What alternatives have you considered?

Activity

benjamingr commented on Jan 5, 2024

jacob-ebey commented on May 9, 2024

avivkeller commented on May 15, 2024

cjihrig commented on Aug 27, 2024

avivkeller commented on Aug 27, 2024

jacksonthall22 commented on Sep 26, 2024

krutoo commented on Mar 9, 2025

krutoo commented on Mar 9, 2025

krutoo commented on Mar 19, 2025

12 remaining items

leoschweizer commented on Aug 5, 2025

p-mcgowan commented on Aug 5, 2025

github-actions commented on Feb 2, 2026

styfle commented on Feb 3, 2026

filmaj commented on Feb 9, 2026

vassudanagunta commented on Mar 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions