-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using node:test
with Custom ESM Loaders
#46292
Comments
FWIW here's the workaround I'm using on a project of mine: // test/index.ts
import fs from "node:fs/promises";
async function* findTestFiles(url) {
for await (const dirent of await fs.opendir(url)) {
if (dirent.name === "node_modules" || dirent.name.startsWith(".")) continue;
if (dirent.isDirectory())
yield* findTestFiles(new URL(`${dirent.name}/`, url));
else if (dirent.name.endsWith(".test.ts")) yield new URL(dirent.name, url);
}
}
for await (const file of findTestFiles(new URL("../", import.meta.url))) {
await import(file);
} And I have this in my {
"scripts": {
"test": "node --loader '#ts-loader' test/index.ts",
"test-only": "node --test-only --loader '#ts-loader' test/index.ts"
}
} The above "just works" if you're using You can also specify custom loader hooks in the But I guess what you meant was asking for a solution to provide custom file extensions / file name patterns for |
Thanks for the concise and helpful Yes, I'm advocating for direct support of custom loader files in the test suite. It would allow for leveraging features like parallelization in the new |
Ideally I would love if the test runner can support a glob expression, that will require glob support in core |
What is the problem this feature will solve?
The builtin
node:test
functionality does not accommodate Custom ESM Loaders for specifying tests. The documented test-runner-execution-mode only matches.js | .cjs | .mjs
extension files.What is the feature you are proposing to solve the problem?
Ideally, the test-runner-execution-mode would allow for registered Custom ESM Loaders automatically. If not possible, specifying allowed file extensions via environment variable would work.
What alternatives have you considered?
Current workaround is a manual shim -- using a standard file extension and importing the Custom ESM modules from there.
The text was updated successfully, but these errors were encountered: