AssertionError when debugging in VS Code

[Basssiiie]

Hey I've been using the VS Code debugger launch configuration from here for quite a while now, but since updating to V4 I cannot get it to work anymore. Whenever I run it, I run into this error on any of the test files:

  Uncaught exception in tests\temp.tests.ts

  AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:

    assert(refs.runnerChain)


  × tests\temp.tests.ts exited with a non-zero exit code: 1
  ─

  1 uncaught exception

The example test file used (the error occurs on any test file though):

import test from "ava";

test("ava test", t =>
{
	t.pass();
});

The VS Code launch.json (exact copy from the linked docs):

{
	"version": "0.2.0",
	"configurations": [
		{
			"type": "node",
			"request": "launch",
			"name": "Debug AVA test file",
			"runtimeExecutable": "${workspaceFolder}/node_modules/.bin/ava",
			"runtimeArgs": [
				"${file}"
			],
			"outputCapture": "std",
			"skipFiles": [
				"<node_internals>/**/*.js"
			]
		}
	]
}

AVA configuration in package.json:

	"ava": {
		"extensions": [
			"ts"
		],
		"files": [
			"tests/**/*.tests.ts"
		],
		"require": [
			"./tests/_setup.js",
			"ts-node/register"
		],
		"verbose": true
	}

Running npx ava --version reports 0.1.0? I have 4.0.1 installed according to the package.json and the node_modules/ava folder and both npm install and npm update do not change that.

AVA debugging still works in another project running 3.15

This sounds like a bug right?

Thank you for your time!

[novemberborn]

That is peculiar. Are you breaking on (un)caught exceptions by any chance? I think this would occur if the test file is run directly, though going by the configuration I wouldn't expect that to happen.

Does debugging work through use VS Code's "debug terminal" feature?

There's a known issue where npx ava --version prints "unknown". No idea why it would print 0.1.0, maybe something is wrong somehow somewhere with that.

[Basssiiie]

Both "caught exceptions" and "uncaught exceptions" are unchecked. I removed all my other breakpoints as well but it still happens regardless of having breakpoints.

Using the Javascript Debug Terminal and running npx ava does work as expected though. :) (Though it runs through all files, but that's probably intended.)

[Basssiiie]

I know nothing about the internals of AVA but I did find this assert, and the refs it is importing is initialized as null in state.cjs. I don't see it being overwritten/changed in the code around it. Might that be something?

[novemberborn]

(Though it runs through all files, but that's probably intended.)

You can provide a specific test file as an argument.

I know nothing about the internals of AVA but I did find this assert, and the refs it is importing is initialized as null in state.cjs. I don't see it being overwritten/changed in the code around it. Might that be something?

It is the problem, but under normal execution it is supposed to be assigned. The question is why is that not happening.

[Basssiiie]

Alright thank you for your time. If you still need any more info regarding solving this issue, please let me know. :)

[ctjlewis]

Running into this, very weird. Running yarn add ava and then testing works, but after the second run I encounter the issue here.

refs.runnerChain remains null, and the Runner never starts and changes it. Version logs 0.0.1. My hunch is it has to do with Node module loader caching?

[novemberborn]

My hunch is it has to do with Node module loader caching?

Interesting hunch! Though the tests run in fresh worker threads so I wouldn't expect any caching to be in play. Does it work if you configure AVA with workerThreads: false?

[Basssiiie]

For me setting "workedThreads": false in the AVA config in package.json, or adding --workerThreads=false as a cmdline argument, did not work unfortunately. I still get the same error.

[johndeighan]

I am also encountering this error. Unfortunately, the only option that I have at this point is to stop using ava. I did try completely clearing the node module cache, after rebooting, and it didn't change a thing. I should add that I've been using ava 3 for quite some time now without problems, but I'm opposed to continuing to use a library once a new version is released. FYI, I've upgraded ALL instances of ava to version 4 so it's not a problem with mixing versions.

[ctjlewis]

I am also encountering this error. Unfortunately, the only option that I have at this point is to stop using ava. I did try completely clearing the node module cache, after rebooting, and it didn't change a thing.

I just ran into it again a few minutes ago.

It's a caching issue of some kind. rm -rf node_modules/ava && yarn add -D ava got me back to working state.

[novemberborn]

I can't reproduce this.

• AVA 4.0.1
• Node.js 17.6.0 (but not sure if VS Code inherits that)
• VS Code 1.65.0

I tried with a test.mjs and test.cjs file, as in the original post. Debug configuration from the original post.

I did not try with a TypeScript file to then make use of ts-node/register but I did load it. Version 10.7.0.

If somebody could share a project in which this is reproducible I can take another look.

[Basssiiie]

Unfortunate that you weren't able to reproduce it. I just made a new project with:

• AVA 4.0.1
• Node.js 17.6.0 (it was previously 16.11.1)
• VS Code 1.65.0
• TS-Node 10.7.0
• OS: Windows 10.0.19043 64-bit
• npm ava --version: 4.1.0

I did notice VS Code states it's using Node.js version 14.16.0 in the About window, but I don't know if that one is used for debugging as well. Update: running node --version VS Code debug task prints 17.6.0.

The project: ava-error-project.zip

It's nothing more than...

npm init
npm install ava ts-node -D

Plus the launch.json, AVA config in package.json and two test files.

The problem unfortunately still occurs in both Typescript and regular CJS files. It also occurs without TS-Node (after removing it). They all give:

[D:\ava-error-project/node_modules/.bin/ava.CMD]() [d:\ava-error-project\tests\javascript.cjs]()
Debugger attached.

  Uncaught exception in tests\javascript.cjs

  AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:

    assert(refs.runnerChain)


  × tests\javascript.cjs exited with a non-zero exit code: 1
  ─

  1 uncaught exception
Waiting for the debugger to disconnect...

If it cannot be fixed, it seems I'll have to stay on version 3.x indefinitely.

[ctjlewis]

It's not surprising that you couldn't reproduce it because it's a nondeterministic bug.

Closing this issue is inappropriate but you're free to do it, though that would mean this software is no longer being actively maintained.

[novemberborn]

Thanks @Basssiiie — I'm on a different machine now, so Node.js 16.13.0 which I happen to have installed. It's all working fine. I wonder if this is a Windows issue? I'm on Mac. What are the others using?

Under normal circumstances this really shouldn't be happening. AVA sets up refs.runnerChain before the test file is loaded. It feels as if, when the VS Code launch config is active, somehow the runtime behaves in a non-standard manner, not reusing instantiated modules when they're imported from different files.

I don't think that's due to AVA itself. It could either be VS Code or ts-node. Probably VS Code.

This presumed non-standard behavior also makes this really hard to debug and understand.

[novemberborn]

@ctjlewis please understand that I maintain AVA as a hobby — I have plenty of work obligations and non-computer stuff to get on with. I'd appreciate it if you'd bring a constructive and positive attitude to your comments here, rather than dismissing my efforts. Sometimes it can be better not to press that "Comment" button.

[TheBrenny]

So I could be completely wrong, and there could be some huge voodoo JS-magic that's happening, but maybe it's CJS thing rather than ESM?

// ./lib/worker/main.cjs
const {flags, refs} = require('./state.cjs');
assert(refs.runnerChain);

// ./lib/worker/state.cjs
exports.refs = {runnerChain: null};

Wouldn't this more or less be equivalent to assert(false) with extra steps? Requiring a file which defaults a thing to null, and then asserting that the thing shouldn't be null will always error? Or I'm wrong, an there is some ESM magic happening...

[novemberborn]

@TheBrenny it's assigned here:

ava/lib/worker/base.js

Line 68 in c5d2b53

refs.runnerChain = runner.chain;

This is the code that is managed by AVA. By the time the test file is loaded, which ends up loading lib/worker/main.cjs when it imports 'ava', the chain should be set. Something's really gone wrong if that assertion fails, as we've seen in this discussion. But it's not something I'd expect to happen unless the environment has been tampered with.

[clshortfuse]

import test from 'ava';

test('sync test', (t) => {
  t.pass();
});

test('async test', async (t) => {
  const bar = Promise.resolve('bar');
  t.is(await bar, 'bar');
});

>nvm use v16
Now using node v16.14.2 (npm v8.5.0)
>npx ava test/sanity.js 

  ✔ sync test
  ✔ async test
  ─

  2 tests passed

>nvm use v14
Now using node v14.19.1 (npm v6.14.16)
>npx ava test/sanity.js 
npx: installed 167 in 4.025s

  Uncaught exception in test/sanity.js

  AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:

    assert(refs.runnerChain)


  ✖ test/sanity.js exited with a non-zero exit code: 1
  ─

  1 uncaught exception

It's environment, for sure:

>nvm use v14
Now using node v14.19.1 (npm v6.14.16)
>npm install --save-dev ava

+ ava@4.1.0
added 167 packages from 87 contributors and audited 168 packages in 4.506s

>npx ava test/sanity.js 

  ✔ sync test
  ✔ async test
  ─

  2 tests passed

[novemberborn]

@clshortfuse are you saying this is a Node.js 14 issue? Why does it work the second time? And what OS are you using?

[clshortfuse]

@novemberborn Sorry for not getting back to you sooner. I have a project that is expected to support v12, v14, and v16.

By default I test on v16. I use nvm v14 and nvm 12 to switch to Node 14 and Node 12, respectively. I would like to be able to just use nvm use v14 which switches my context to NodeJS 14, and then npx ava. Since my ./node_modules are targeting Node v16 by default, I have to do npm install on the current working directory before calling npx ava while using v14.

Therefore, npx ava on v14 without reinstalling ava into the local node_modules will cause the error as shown before to throw. It's rather strange that ava even bothers looking into the local node_modules. I thought it would look at ~/.npm structure. For some reason, when on node v14, it believes ./node_modules/ava is compatible with v14 when it's not. ./node_modules/ava was built when I was on v16.

[novemberborn]

@clshortfuse,

Since my ./node_modules are targeting Node v16 by default, I have to do npm install on the current working directory before calling npx ava while using v14.

In case of compiled binaries, an npm rebuild is generally recommended. That's not AVA specific necessarily.

It's rather strange that ava even bothers looking into the local node_modules. I thought it would look at ~/.npm structure.

No, AVA assumes it's installed locally. npx ava will install from your local node_modules.

For some reason, when on node v14, it believes ./node_modules/ava is compatible with v14 when it's not. ./node_modules/ava was built when I was on v16.

There is no believing here. It just runs with what's there. But the only thing I'd expect to be different, based on the Node.js version under which you install dependencies, are compiled binaries.

[clshortfuse]

@novemberborn Right, but npx "should" know that a module should be recompiled. I did a bit more researching. I think it was an npm bug on whatever is default v14. I got a fresh package but updated npm on v14 and no issue. I could research where and what version of npm shows the issue, but not worth the hassle. If anybody has this, it's an external npm bug, not related to the project.

But if you look at the previous comment, npm was on v6 when on node v14. This is now both node v14 and node v16 both on npm v8:

$ nvm use v16
Now using node v16.14.2 (npm v8.5.0)
$ npm install --save-dev ava

up to date, audited 168 packages in 570ms

47 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
$ npx ava

  ✔ sync test
  ✔ async test
  ─

  2 tests passed
$ nvm use v14
Now using node v14.19.1 (npm v8.6.0)
$ npx ava

  ✔ sync test
  ✔ async test
  ─

  2 tests passed

So, npm install -g npm and it goes away, basically.

[mil7]

Just for the record. This thread has been very useful for me. Thanks!

Using the VLC launch.json to debug AVA v4 tests ends with the same strange error message as mentioned here. Using the JavaScript Debug Terminal and trigger the breakpoints with npx ava ./path/to/testcase.ava.js does the trick though. This workaround is good enough for me.

Downgrading to AVA v3 also helps to overcome the stubborness of VSC.

I am also developing on Windows 10 and with the combination of recent Node.js v14 and default npm v6. But I can reproduce the issue with Node.js v16 and npm v8 as well.

[AlencarGabriel]

I had the same problem reported by @Basssiiie when debugging my javascript project on windows. I solved by adjusting the launch as follows:

{
    "type": "node",
    "request": "launch",
    "name": "Debug AVA test file",
    "program": "${workspaceFolder}/node_modules/ava/entrypoints/cli.mjs",
    "args": [
        "${file}"
    ],
    "outputCapture": "std",
    "console": "integratedTerminal",
    "skipFiles": [
        "<node_internals>/**/*.js"
    ]
}

[novemberborn]

@AlencarGabriel which change was critical? Pointing at the cli.mjs entrypoint (rather than the binstub installed by npm), or the console setting?

[AlencarGabriel]

Hi @novemberborn , pointing to the cli.mjs entry point. Running ava.cmd directly does not result in errors, only when run via launch in VsCode.

[Basssiiie]

@AlencarGabriel @novemberborn Your launch.json works for me as well! I can debug in VS Code again! 🥳

Another difference is that it's using program and args keys instead of runtimeExecutable and runtimeArgs, which are apparently different.

See the diff of the new file here:

[novemberborn]

@AlencarGabriel lovely! Would you want to open a PR to change the recommended configuration?

[AlencarGabriel]

@AlencarGabriel lovely! Would you want to open a PR to change the recommended configuration?

Done. Glad I could help!

[bricker]

I ran into this issue even using the configuration recommend in this thread, and wanted to share the problem and solution for other Googlers.

TL;DR

Different copies of ava were being used/imported. To fix, remove the copies or ensure you're importing the same copy (as in, the same files on disk/memory) that was used to run the tests.

Long answer

My project has nested package.json files (and nested node_modules), and each package specified ava as a dev dependency, like this:

- package.json
  - devDependencies: ava
- node_modules
  - ava
- packages
  - packageA
    - package.json
      - devDependencies: ava
    - node_modules
      - ava
  - packageB
    - package.json
      - devDependencies: ava
    - node_modules
      - ava

So there were multiple copies of ava installed in the project. My launch.json file was running (root)/node_modules/ava/entrypoints/cli.mjs (as recommended in this thread), but the test files were importing their own copy of ava (eg from (root)/packages/packageA/node_modules/ava/. refs.runnerChain is a global state in each copy of ava, so with different copies being imported, refs.runnerChain was set in one copy but not the other, hence the error.