Repository navigation
--test-name-pattern needing to come before filenames is hostile to npm scripts #51384
Description
Activity
@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 theNODE_OPTIONSenvironment variable as a workaround.I run into this all the time and if I could remove the script
test:targetfor 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_OPTIONSenvironment variable as a workaround.--test-name-patternand--test-skip-patternaren't allowed inNODE_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
Reacted by StevenIf anyone wants to pick this up, it would involve updating the test runner's
parseCommandLine()function to also consider values inprocess.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.execArgvis 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-isolationare 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
--requireor--importinprocess.argvto 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 timenode:testis 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).
Reacted by Steven- The current behavior of only considering
FWIW:
Currently, (without any changes) there are a few ways to achieve this goal (as @benjamingr previously mentioned):run()- You can use therunfunction to specify patternsNODE_OPTIONS- As of cli: allow--test-[name/skip]-patterninNODE_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.
Reacted by Colin IhrigI'll throw in my 2 cents—I'm only just learning about node's testing suite, but it is definitely misleading that both
--testand--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--testshould 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--importsetup file before tests runAlso looks like NODE_OPTIONS not working, i do it like this:
NODE_OPTIONS="--test-name-pattern=\"Vector\"" npm run testIt becomes to:
node --import ./scripts/setup-tests.ts --test ./src/**/*.test.{ts,tsx}I also have
.npmrcwith: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-patternflag after a--testflag and after files glob?And will there be such a feature?
- marked Explicit glob argument for test runner? #58033 as a duplicate of this issue
on Apr 26, 2025 12 remaining items
@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.Reacted by Pat McGowan@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-staleReacted by Pat McGowan and Toni VillenaNote 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", } }I think the underlying problem is that running tests should be a distinct command, e.g.
node testornode-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 --inspectandnode 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" -kThere are ways to intelligently deal with the backward compatibility concerns of introducing a
node testsubcommand. Note we already havenode inspect. Alternatively, a separatenode-testexecutable would give the same benefits, without any backward compatibility issues at all.Reacted by Domenic Denicola, Steven and Fil MajReacted by Domenic Denicola and Steven- added a commit that references this issue
on Jul 28, 2026 - added a commit that references this issue
on Sep 17, 2026
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.will not work, because this gets translated to
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 isbut 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
--testis present,nodegrabs the--test-name-patternargument 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 runinto 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.