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

[SoonIter]

Describe the bug
A clear and concise description of what the bug is.
I installed vitest V0.18.0,and it doesn`t work.

To Reproduce
Steps to reproduce the behavior on the example project:

1. npx degit SoonIter/sooniter-lib-template-monorepo my-lib-name
2. run ni
3. go to the "test" folder
4. run this one is Ok,

but the extension works fail

Expected behavior
work well

Screenshots

Maybe the problem is to run-once or run-watch.
Version 0.2.20

[SoonIter]

After downgrading the vitest to @0.15.2, it works well.

[beorn]

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

v17.0.0 release notes

[watonyweng]

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

[SoonIter]

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

OK, it now works well with vitest v0.18.1

[beorn]

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"
  }

[jdk2pq]

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

[maggie9595]

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

same!

[laozhu]

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

pnpm monorepo here with vitest 0.19.1, the same problem.

[geekox86]

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.

[justin0mcateer]

Same problem for me...

[rokbot]

check the docs of Vitest vitest docs options Do not watch option --run
you can see more on this #31

[rokbot]

you may also need to do this

[rokbot]

[beorn]

@rokbot So it seems it doesn't hang anymore - it runs - but test results are not found. It helps troubleshooting the issue, but it's not a workaround as far as I can see?

[xieyuheng]

I wish this can be fixed soon ~

[Pustinyak]

The issue here is actually fixed and the "Test result not found" error comes from wrong configuration.

This extension depends on the watch function of vitest. We aren't supposed to run it with vitest run because it messes with the API connection. Remove run from your vitest.commandLine and don't forget to include -- to the line if it calls an external script, otherwise the API wouldn't be started at all.

[xieyuheng]

@Pustinyak I tried:

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

they all have the same issue.

[xieyuheng]

@Pustinyak what version of vitest you are using?

[Pustinyak]

Hey @xieyuheng, I should've mentioned that my solution is better suited for monorepo. I see in your cicada-next repo you have the latest version, so does it work for you now? I'm also using the latest one.

[beorn]

Any update on this? This extension seems broken for the latest 3 months of vitest releases (starting with v0.17.0), and there are quite a few duplicated issues/reports about it.

I haven't found a workaround... If you have any — please share.

[rokbot]

@beorn This seems to be fixed with some workaround/tool and [kudos to the development team 🎉 ]. I will edit some of my posts to match the current state of this and help others troubleshoot this issue

[rokbot]

I tried once the solution proposed by @Pustinyak but sadly doesn't work for me

[rokbot]

The steps that worked for me and probably for you are these:

1. First you will need a tool from the awesome @antfu 😎 if you don't have it yet

npm i -g @antfu/ni

2. Then if you ran npm init vue@latest and add vitest in the prompts you will get in your package.json the script test:unit so put that in your workspace settings for Vitest extension like nr test:unit (see the image below)
3. Run the tests in vscode, (and doesn't matter what package manager you are using which is something very nice) you should get something like these:
   

[c00]

I am also experiencing this issue. Using vitest 0.16.0 works fine, any version above that does not.

One important note is that on working versions (0.16.0) there's a log message "WS Open", indicating the plugin is connecting to the vitest API (which I assume it needs for getting results).

On later versions, "WS Open" never happens, and instead "WS Close" gets spammed near endlessly.

Looking at the Release notes for 0.17.0, the thing that stands out to me is "Vite HMR support". I'm not smart enough to figure anything more out than this, but my bet is that something changed in the vitest API in this PR that is now causing the plugin to be unable to connect.

[c00]

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.

[knoopx]

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).

[falynx]

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.

[hiepxanh]

@falynx great, but I already try on window and it seem not work, did I do correct?

[falynx]

@hiepxanh Hmm, your file setup looks fine, but you seem to be receiving a few different errors that may not be related. So instead of starting with your particular setup, why don't we start from the vitest sample project as a baseline.

Here are the steps:

1. If you've been messing around with the extension code, reinstall it to make sure it's clean with no modifications.
2. Ensure you don't have any straggling vitest commandLine settings. Make sure all settings are clean/default.
3. git clone https://github.com/zxch3n/vitest-ext-basic-example
4. cd vitest-ext-basic-example
5. pnpm update --latest
6. mv node_modules/vitest/vitest.mjs node_modules/vitest/vitest.real.mjs
7. code node_modules/vitest/vitest.mjs
8. Copy/paste the code above into the file and save it. NOTE: I altered the code snippet since last night to fix a different bug, so be sure to copy it again.
9. Close the vscode window
10. Open the vitest-ext-basic-example folder with vscode
11. Confirm that a Vitest statusbar button is now shown
12. Click the Vitest statusbar button and confirm that it activates. It should say "1/1 passed (100%, 0 skipped)". It should NOT say "Vitest running..." with a spinner forever.
13. Open up add.test.ts
14. Click the Test inspector button on the left side of vscode and click the test buttons.
15. Tweak the test to make it fail, pass, whatever. Everything should work as expected.

I see that you're using @vitest/ui. That should be working fine, too. Steps:

1. pnpm add -D @vitest/ui
2. pnpm vitest --ui
3. Confirm that it loads up add.test.ts in your browser.
4. Tweak the test. Confirm that the results are updated in realtime in the browser and in the terminal window.

All of that is working fine for me here on my Windows 11 system. If it's not working for you, then I'm not sure what to tell you. If it is, then that should be a good baseline for you to debug the issue with your larger project.

[falynx]

I just submitted a pull request to migrate this extension to Vite 3.0.

If you prefer to fix/modify your extension rather than using the vitest wrapper script above, follow these steps:

1. git clone https://github.com/falynx/vscode
2. yarn install (might need to pnpm add -g yarn first)
3. yarn vscode:prepublish
4. Overwrite %USERPROFILE%\.vscode\extensions\zixuanchen.vitest-explorer-0.2.29\dist\extension.js with dist/extension.js
5. Restart vscode (make sure you removed any commandLine settings, wrapper scripts, etc.)

Only tested on Windows 11.

[hiepxanh]

merged @falynx 💘 you did great, good job

[zxch3n]

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

[lielgut]

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

I have v0.2.32 installed and i'm still getting this problem. anyone knows how to fix this?

[c00]

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?

[abarke]

In my case I was using vite v4.x.x out of the box and that didn't work using the VS Code Extension. To fix it I had to force vite v3.x.x