How to run the Node built-in testrunner for TypeScript files inside a specific directory?

[jtuchel]

Details

I want to replace Mocha tests with the built-in testrunner. All tests are inside a test directory and follow the pattern

...Tests.ts

I started with a fooTests.ts file

import assert from 'assert/strict';
import test from 'node:test';

test('1 is equal to 1.', () => {
  assert.strictEqual(1, 1);
});

and added the npm script

"test": "node --test ./test/**/*Tests.ts",

The script fails with the message

Could not find '/home/.../test/**/*Tests.ts'

How can I fix the script to

• test files matching the path ./test/**/*Tests.ts only
• run with TS files ( I'm pretty sure I must use ts-node for this )

? Thanks in advance!

Node.js version

v18

Operating system

Linux ( Ubuntu 22.04 )

Scope

Built-in testrunner

Module and version

Not applicable.

[adrienjoly]

Did you try injecting a TypeScript processor as a command line parameter for node, yet?

E.g. node --require @swc/register [...] or node --require ts-node/register [...]

[neodon]

In case it helps anyone who runs across this issue, here is how I currently execute tests written in TypeScript with the new node test runner and esbuild-kit/tsx:

npm install -D tsx

Add the following npm script entry:

"test": "node --loader tsx --test test/**/*Test.ts"

Let me know if this is helpful.

Edit: See the reply below by @scottwillmoore for an excellent tip to make this work more robustly across platforms.

[jtuchel]

@neodon I tried to reproduce your approach but I get a "not found" error ( I'm using Node 19 )

tsconfig.json

{
    "compilerOptions": {
        "baseUrl": ".",
        "declaration": true,
        "esModuleInterop": true,
        "lib": ["es2022", "dom"],
        "module": "commonjs",
        "outDir": "build",
        "resolveJsonModule": true,
        "strict": true,
        "target": "es2022"
    },
    "include": ["./**/*.ts"],
    "exclude": ["./build"]
}

package.json

{
    "scripts": {
        "test": "tsc --noEmit && node --loader tsx --test test/**/*Tests.ts"
    },
    "dependencies": {
        "@types/node": "18.11.9"
    },
    "devDependencies": {
        "tsx": "3.11.0",
        "typescript": "4.8.4"
    }
}

./test/someTests.ts

import assert from 'assert/strict';
import { describe, it } from 'node:test';

describe('tests', () => {
    it('passes', () => {
        assert.ok(true);
    });
});

The test script fails with

Could not find '/home/.../repository/test/**/*Tests.ts'

Did I miss something?

[scottwillmoore]

EDIT:

See this example repository which I have created.

Problem

I haven't tested your environment, but if I had to guess I believe it is your npm script which is incorrect:

tsc --noEmit && node --loader tsx --test test/**/*Tests.ts

On a POSIX system npm will execute the script with /bin/sh. The pattern test/**/*Tests.ts is not expanded by node or npm it is up to /bin/sh to expand it. However, **, also known as globstar is not supported by /bin/sh, it is not being expanded as you would expect. The globstar is supported by /bin/bash, but must be enabled.

Solution

I could be wrong, but I believe since globstar is not supported, the pattern test/**/*Tests.ts becomes test/*/*Tests.ts which will only match files in a subdirectory of your test folder, such as test/abc/xyzTests.ts. If you just wanted to match tests in the root of the test folder, you could rewrite the pattern as test/*Tests.ts, which would match tests/xyzTests.ts, but would not match files in a subdirectory of your test folder.

Better Solution

It would be better to rewrite the script in a cross-platform manner, instead of relying on platform dependent features in your scripts which is may be unreliable. This way your script should even work on Windows.

There might be an easier way to leverage another package, but I think I would just move it into a JavaScript or TypeScript script.

Change your script to:

tsc --noEmit && node --loader tsx runTests.ts

Then create a file named runTests.ts.

I don't have the time to experiment with a full script, but I expect you would want to use the glob package to get the list of files and the child_process Node API to then call node --loader tsx --test ....

Related

Why can't ** be used (for recursive globbing) in a npm package.json script, if it works in 'npm shell'?

Why you should always quote your globs in NPM scripts.

Follow Up

I originally wrote this answer of StackOverflow, but perhaps someone here has an easier solution than writing your own script. Also, I hope I've actually diagnosed the issue, otherwise that would be a little awkward 😬 .

[webpro]

Another option to run the same command on Windows as well is to use globstar:

{
  "scripts": {
    "test": "globstar -- node --loader tsx --test \"test/**/*.spec.ts\""
  }
}

(Last release of this package seems to be 8 years ago, but still does the job.)

[Ethan-Arrowood]

@scottwillmoore I was trying out your example and in Node v20, it now breaks with:

node-test-with-typescript on  main [!] via 🤖 v20.0.0 on ☁️  production 
❯ npm test  

> test
> node --loader tsx --no-warnings script/test.ts

/Users/ethanarrowood/Documents/github/vercel/vercel-azure-devops-extension/node-test-with-typescript/script/test.ts:1
import { execSync } from "node:child_process";
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at internalCompileFunction (node:internal/vm:73:18)
    at wrapSafe (node:internal/modules/cjs/loader:1187:20)
    at Module._compile (node:internal/modules/cjs/loader:1231:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1321:10)
    at Module.load (node:internal/modules/cjs/loader:1125:32)
    at Module._load (node:internal/modules/cjs/loader:965:12)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:165:29)
    at ModuleJob.run (node:internal/modules/esm/module_job:192:25)

Node.js v20.0.0

The simplest solution I found was to add "type": "module", to my project's package.json

[scottwillmoore]

You're right! This does not happen in Node 19 with 19.0.1, or even 19.9.0, but it does happen in Node 20 with 20.0.0. The error message appears to indicate that the TypeScript is not getting transpiled into CommonJS, but instead to ModuleJS. But, with no changes to the loader tsx and other dependencies, this must have been caused by a change in Node 20? However, I couldn't find any concrete reason in the changelog for Node 20.

The solution, as indicated with @Ethan-Arrowood is to just add "type": "module" to your package.json, therefore Node will accept the TypeScript that is transpiled to ModuleJS. I've updated my example repository to reflect these changes. To be honest, if you are using the latest version of Node, you probably should use ModuleJS anyway.

I've also double checked, and a custom script is still required to run TypeScript with the Node test runner at the moment. This is due to the current Node test runner execution model. However, there is a feature request to fix this issue: nodejs/node#46292.

[reedHam]

Hmm when I try node --loader tsx --test with node 20 on windows.
I'm getting this error.

node:internal/worker:211
    this[kHandle] = new WorkerImpl(url,
                    ^
This Environment was initialized without a V8::Inspector
Thrown at:
    at Worker (node:internal/worker:211:21)
    at InternalWorker (node:internal/worker:464:5)
    at HooksProxy (node:internal/modules/esm/hooks:496:20)
    at CustomizedModuleLoader (node:internal/modules/esm/loader:351:18)
    at createModuleLoader (node:internal/modules/esm/loader:421:14)
    at get esmLoader (node:internal/process/esm_loader:15:26)
    at node:internal/modules/cjs/loader:119:47
    at node:internal/util:764:15
    at Module.load (node:internal/modules/cjs/loader:1128:26)
    at Module._load (node:internal/modules/cjs/loader:965:12)

[MoLow]

Hmm when I try node --loader tsx --test with node 20 on windows. I'm getting this error.

node:internal/worker:211
    this[kHandle] = new WorkerImpl(url,
                    ^
This Environment was initialized without a V8::Inspector
Thrown at:
    at Worker (node:internal/worker:211:21)
    at InternalWorker (node:internal/worker:464:5)
    at HooksProxy (node:internal/modules/esm/hooks:496:20)
    at CustomizedModuleLoader (node:internal/modules/esm/loader:351:18)
    at createModuleLoader (node:internal/modules/esm/loader:421:14)
    at get esmLoader (node:internal/process/esm_loader:15:26)
    at node:internal/modules/cjs/loader:119:47
    at node:internal/util:764:15
    at Module.load (node:internal/modules/cjs/loader:1128:26)
    at Module._load (node:internal/modules/cjs/loader:965:12)

it seems to be caused by https://github.com/nodejs/node/blob/8becacb25d3c275341a9fef1a94581de3bd60c3d/src/env-inl.h#L638-L641

@nodejs/loaders @nodejs/workers do workers require a v8 inspector in order to work?

[JakobJingleheimer]

This sounds familiar

nodejs/node#44710 (comment)

I think it ended up being a red-herring.

[webpro]

A potential solution to the OP is to pre-compile TS to JS. Then you don't need a loader and with more than two unit tests it becomes a lot faster too, since you compile everything only once and no further overhead. (example commit that does this using swc).

[GeoffreyBooth]

I think it ended up being a red-herring.

Are you sure? I think it was a red herring for that PR in that Node’s internal test runner doesn’t use --test, so the command you were using for one-off testing in that comment wasn’t working but the actual Node tests were passing. But I think maybe it really is a bug that --test and --loader can’t be used together at the moment, because of https://github.com/nodejs/node/blob/8becacb25d3c275341a9fef1a94581de3bd60c3d/src/env-inl.h#L640. cc @MoLow