vscode: [not support vitest@v0.18.0] test successfully, but loading infinitely.

The latest vitest extension release, v0.2.20 (from 15 days ago), doesn’t work with vitest v0.18.1 for me. Just get an infinite spinner.

Try the example project linked to above with this:

  "devDependencies": {
    "envinfo": "^7.8.1",
    "vite": "^3.0.0",
    "vitest": "^0.18.1"
  }

Update: The cause of the problem is that vitest tends to bind the API on ::1 (ipv6) while the plugin tries to connect on 127.0.0.1 (ipv4).

I guess vitest and the plugin both resolve localhost in a different way. That’s weird and unfortunate.

We can force vitest to listen on the ipv4 address by passing --api.host 127.0.0.1 to it, and that does make everything work. Unfortunately we can’t currently put that in the vitest.commandLine, as the plugin sets --api [port] which overwrites that.

However, if we would change the plugin code to use --api.port [port] instead, then we would be able to do this. I will create a PR to do this.

I don’t see any possible issues this could cause. All it does is create the option for people with this issue to add the host to the command line, working around the problem.

The true solution would be to resolve localhost in the same way as vitest or forcing vitest to bind on whatever the plugin resolves to. However, this is a bit out of my comfort zone. It’s probably better to come up with a solution that works (tho isn’t perfect) than to ask an open-source maintainer to do work for me.

you may also need to do this

Same issue as @beorn. I think this issue should be re-opened.

v0.2.31 includes the fix from @c00 and @falynx 🎉. Thank everyone’s effort here.

adding to @c00 reply, a temporary workaround is to prepend require("node:dns").setDefaultResultOrder("verbatim"); to ~/.vscode/extensions/zixuanchen.vitest-explorer-0.2.29/dist/extension.js. I spent the whole day troubleshooting and re-witting most of the extension yesterday, I think it needs to be re-architectured to work a different way (to not manually look and parse specs and to just spawn vitest watch server, and trigger manual re-runs via WS instead).

Greetings. Same here.

I can run the tests and they pass from the terminal. However, running them from the extension gets the indicator spinning forever.

BTW, I also cloned your repo to test with your samples and the issue still exists.

macOS Big Sur 11.6.5 Version: 1.70.0-insider

“typescript”: “^4.7.4”, “vite”: “^3.0.4”, “vitest”: “^0.20.2”

Please, help.

Same issue as @beorn. I think this issue should be re-opened.

same!

For me it’s working out of the box now.

• Is your vitest.commandLine set to anything? If so, try clearing it.
• Does your vite.config set any api related settings? if so try removing those.
• Is Vite version 3.1.x?
• Is vitest version 0.24.x?

If this doesn’t help, what OS are you on?

Update: The cause of the problem is that vitest tends to bind the API on ::1 (ipv6) while the plugin tries to connect on 127.0.0.1 (ipv4)

I guess vitest and the plugin both resolve localhost in a different way. That’s weird and unfortunate.

We can force vitest to listen on the ipv4 address by passing --api.host 127.0.0.1 to it, and that does make everything work. Unfortunately we can’t currently put that in the vitest.commandLine, as the plugin sets --api [port] which overwrites that.

However, if we would change the plugin code to use --api.port [port] instead, then we would be able to do this. I will create a PR to do this.

I don’t see any possible issues this could cause. All it does is create the option for people with this issue to add the host to the command line, working around the problem.

The true solution would be to resolve localhost in the same way as vitest or forcing vitest to bind on whatever the plugin resolves to. However, this is a bit out of my comfort zone. It’s probably better to come up with a solution that works (tho isn’t perfect) than to ask an open-source maintainer to do work for me.

I fixed a lot of this a few days ago. To be clear, this all broke with the release of Vite 3.0 (3.0.0-alpha.11, to be exact). It happened with this commit where they changed the default host from 127.0.0.1 to localhost. But there was also a problem (in Windows, at least) where the “Debug Test” was failing because the test file path being passed to vitest was not being properly compared, so it would never pass their filter match. They’re using a glob module, which makes use of process.cwd(), and that (for some reason) was converting the drive name in the file path from C:/ to c:/, which differs from the C:/ filter being passed from the vscode plugin. In vitest, they’re doing a case-sensitive match with .includes(), which obviously fails. Anyway, I modified my vscode plugin extension to use --api.port and --api.host, and I also made it use process.cwd() to construct the test file path so that it would have the same capitalization that vitest produces with its glob matching module. This is just a workaround, though, not a “proper” fix. The vitest code is in some serious need of refactoring.

If anyone is interested, I can post the modified vscode extension file in a fork of this project. Alternatively, there is another option for people who don’t want to modify their extension. Here’s a little wrapper for vitest.mjs that I wrote that intercepts calls to vitest, “fixes” the arguments passed in, and passes them along to the real vitest.mjs.

// node_modules/vitest/vitest.mjs
import path from 'path';
import { spawnSync } from 'node:child_process';

const [ node, module, ...origArgs ] = process.argv;
const args = origArgs.map((arg, i) => {
  if (arg === '--api') {
    return '--api.port';
  }
  if (origArgs[i - 1] === '-t') {
    return arg.replace(/[$^+?()[\]]/g, '\\$&');
  }
  if (/\.(?:js|mjs|cjs|ts|mts|cts|jsx|tsx)$/.test(arg)) {
    const cwd = process.cwd();
    return path.join(cwd, path.relative(cwd, arg));
  }
  return arg;
});

if (!args.includes('--api.host')) {
  args.push('--api.host', '127.0.0.1');
}

spawnSync(node, [module.replace(/\.m?js$/, '.real$&'), ...args], { stdio: [0, 1, 2] });

To use it, you can simply install the latest vite and vitest, rename vitest.mjs to vitest.real.mjs, and create a new vitest.mjs with the code above. If you want this to work for future projects, you can use pnpm link or whatever to make all of this easier with symlinks. You don’t have to bother modifying the vitest plugin’s commandLine option this way. The commandLine option isn’t even used by the plugin’s statusbar button. Instead, it scans your node_modules directory in your project directory for vitest.

@Pustinyak I tried:

"vitest.commandLine": "npx vitest",
"vitest.commandLine": "npx vitest watch",

they all have the same issue.

I wish this can be fixed soon ~

Same problem for me…

Hi @SoonIter ,Please upgrade vitest to the latest version.

OK, it now works well with vitest v0.18.1

Hi @SoonIter ,Please upgrade vitest to the latest version.

The last working version is vitest 0.16.1 — the extension is broken fromvitest 0.17.0.

v17.0.0 release notes