Ari Perkkiö

I think it showed up when using `DEBUG=vite-node:*` envrionment variable. > Vite has [inspect](https://github.com/antfu/vite-plugin-inspect) that seems could help here but I don't see how I can use it with vitest...

> rather have the ability to tell `istanbul` or `c8` the `coverageRoot` @Jason3S If you can share a minimal reproduction repository for the `istanbul` case, I'm quite sure we can...

[`[email protected]`](https://github.com/bcoe/c8/pull/428) will add support for passing reporter options. I think this issue reported by @alexlafroscia can then be fixed in Vitest. The release has not yet been made though. I...

> I tried changing `root`, but that doesn't seem to make a difference. I see the problem now. Using Vitest's `config.root` as reporters' `projectRoot` can be used as default value...

@alexlafroscia now that the new `@vitest/coverage-v8` is replacing `@vitest/coverage-c8` and we are no longer limited by `c8`, this issue should be resolved. Could you test whether the new package works...

Closing as there has been no activity since last request. Both coverage providers should be able to provide this functionality now.

I've been able to step into Vitest test cases with debugger even when threads are enabled. Not sure if `vitest --inspect-brk` works but pass it directly to `node` and it...

The VSCode's `autoAttachChildProcesses` seems to do some magic indeed. With latest Vitest release I'm also unable to attach to test cases without using `autoAttachChildProcesses`. But by modifying the sources so...

This is fixed on Svelte 5.

While updating `eslint-remote-tester` to support ESLint v9 and FlatConfig, I converted it (and `eslint-remote-tester-repositories`) to ESM as I needed top level async in one file. To fix the error of...