Ava v4 - `Runtime error: TypeError: Cannot read property 'ref' of undefined`

[vjpr]

Issue description or question

See: https://github.com/avajs/ava/issues/2850

I original opened the issue in Ava, but I think it might be more of a Wallaby issue.

Does Wallaby do anything custom in setting up the comms channel between itself and Ava workers?

When Wallaby run's ava:

const {isMainThread} = require('worker_threads');

=> true

However Ava doesn't expect it to be a main thread, so handle is never set.

let handle;
if (isRunningInChildProcess) {
    const {controlFlow} = require('../ipc-flow-control');
    handle = new IpcHandle(controlFlow(process));
} else if (isRunningInThread) {
    const {parentPort} = require('worker_threads');
    handle = new MessagePortHandle(parentPort);
}

// The attaching of message listeners will cause the port to be referenced by
// Node.js. In order to keep track, explicitly reference before attaching.
handle.ref();

'use strict';

const {isMainThread} = require('worker_threads');

exports.isRunningInThread = isMainThread === false;
exports.isRunningInChildProcess = typeof process.send === 'function';

---

2021-09-27T16:11:49.839Z workers Sandbox (active) [s6g39] error: Cannot read property 'ref' of undefined
Runtime error: TypeError: Cannot read property 'ref' of undefined
    at Object.<anonymous> (./node_modules/.pnpm/ava@4.0.0-alpha.2_d9427be2a42752c1fe4520f1b97b7be4/node_modules/ava/lib/worker/channel.js:101:8)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:94:18)
    at Object.<anonymous> (./node_modules/.pnpm/ava@4.0.0-alpha.2_d9427be2a42752c1fe4520f1b97b7be4/node_modules/ava/lib/worker/base.js:22:17)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:94:18)
    at Object.<anonymous> (./node_modules/.pnpm/ava@4.0.0-alpha.2_d9427be2a42752c1fe4520f1b97b7be4/node_modules/ava/lib/worker/main.js:2:16)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:196:29)
    at ModuleJob.run (node:internal/modules/esm/module_job:183:25)
    at Loader.import (node:internal/modules/esm/loader:178:24)
    at importModuleDynamicallyWrapper (node:internal/vm/module:437:15)

[vjpr]

I think I found the issue. ava@4.0.0-alpha.2 has a check to see if its being run from the CLI - which I think might break Wallaby - unless you are already working around this somehow...

https://github.com/avajs/ava/blob/v4.0.0-alpha.2/lib/worker/base.js#L8-L20

// Check if the test is being run without AVA cli
if (!isRunningInChildProcess && !isRunningInThread) {
    const chalk = require('chalk'); // Use default Chalk instance.
    if (process.argv[1]) {
        const fp = path.relative('.', process.argv[1]);

        console.log();
        console.error(`Test files must be run with the AVA CLI:\n\n    ${chalk.grey.dim('$')} ${chalk.cyan('ava ' + fp)}\n`);

        process.exit(1);
    } else {
        throw new Error('The ’ava’ module can only be imported in test files');
    }
}

Wallaby Console

console.error: Test files must be run with the AVA CLI:

    $ ava ../../../wallaby/server.js

[vjpr]

~I think the issue might have been that I am setting runner as a shell file:~

#!/bin/sh

node \
--no-warnings \
--experimental-loader=$pkgdir/node_modules/@live/esm-loader/index.js \
--experimental-specifier-resolution=node \
--experimental-import-meta-resolve \
--experimental-vm-modules \
--conditions=$CONDITIONS \
"$@"

The env.params.runner is not the same as the args passed into the Node worker process. Maybe env.params.runner are not simply appended to runner as I first thought...

---

I think the problem is related to overriding the --experimental-loader with anything. If I remove this, it works.

---

Ah, so I found it:

execArgv: 
   [ '--experimental-vm-modules',
     '--experimental-specifier-resolution=node',
     '--experimental-import-meta-resolve',
     '--experimental-loader', 'file:///Users/Vaughan/Library/Application%20Support/JetBrains/IntelliJIdeaVaughan/system/wallaby/wallaby/runners/node/ava@1.0.0/hooks.mjs' ]

Wallaby uses a custom hook for ava.

[smcenlly]

Running ava with esm is described in our docs. Was it not working for you? If not, would you mind sharing your Wallaby configuration so we can double check that Wallaby is doing what it should?

[vjpr]

I am working in a pnpm monorepo, and workspace dependencies need to be resolved manually, because node_modules are not present in the projectCacheDir (nor do I want to copy them there).

So I needed a custom loader for that.

I got it working by copying hooks.mjs into my loader's getSource.

[smcenlly]

I assume that this is related to https://github.com/wallabyjs/public/issues/2813? Do you still need help? If you have a sample, we'd love to be able to include it (or share the relevant information) for others.