You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[node:test] Support for file path patterns in run() #48609
It's quite difficult to run test files matching a "file name pattern" when using run() function.
It's easy when using CLI, for example:
node --test src/**/*.test.js
It's difficult because it only allows to pass file paths in files option which means I need to use e.g. glob package to find files when I want to replicate the same behaviour when using CLI.
I see it's possible to still provide test file name pattern as command option when when using run()
node runTests.mjs src/**/*.test.js
but I would like to define file name patterns in runTests.mjs file, based on different conditions.
My use case is to differentiate between unit and integration tests in runTests.mjs
What is the feature you are proposing to solve the problem?
Add new option to run() function
filePathPatterns or filePatterns or testFilePathPatterns - to specify which files test runner should run by glob pattern, like in CLI
type: Array<string>
example filePathPatterns: ['src/**/*.integration.test.js']
Additional option to ignore
It would be great to be able to also ignore some tests by file path pattern
so another option like filePathIgnorePatterns - to specify which files should be ignored by test runner to allow running only selected set of tests (e.g. only integration tests)
I see that internal Glob implementation has an exclude option so that's what I am talking about
What alternatives have you considered?
Using only CLI for running tests, avoid using run()
What you are really asking for is glob being exposed on fs
That would mostly solve my problem indeed.
But I know it will be rather difficult to expose glob in Node.js FS API since agreeing on "the best" API for this function is difficult 😄
I was positively surprised seeing that node:test already uses internal Glob functionality so I thought it will be rather easy and even consistent to use it in run() function also, same as in CLI options
This would also help the typescript case where you pass a --loader but since you can't tell the test runner how to discover files you're left doing the globbing part on your own.
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
Activity
MoLow commentedon Jul 2, 2023
What you are really asking for is
globbeing exposed on fs, so you can runI am +1 on exposing glob, but that requires some more work, with making mini-match more primordials friendly
rluvaton commentedon Jul 2, 2023
an alternative is to use some glob npm package and pass the paths to the files property
mdrobny commentedon Jul 3, 2023
@MoLow
That would mostly solve my problem indeed.
But I know it will be rather difficult to expose
globin Node.js FS API since agreeing on "the best" API for this function is difficult 😄I was positively surprised seeing that
node:testalready uses internal Glob functionality so I thought it will be rather easy and even consistent to use it inrun()function also, same as in CLI optionsmdrobny commentedon Jul 3, 2023
@rluvaton
yep, I mentioned that in the initial description
I need to use e.g. [glob package](https://github.com/isaacs/node-glob) to find files:)but that slightly defeats one of the goals of built-in Node.js test runner - to not install external dependencies to run your tests
jbergstroem commentedon Jul 4, 2023
This would also help the typescript case where you pass a
--loaderbut since you can't tell the test runner how to discover files you're left doing the globbing part on your own.github-actions commentedon Jan 1, 2024
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be 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.