Ari Perkkiö
Ari Perkkiö
Thanks @alexlafroscia, I'm able to reproduce the issue now. We should really wait for support from `c8`'s side for configuring the `test-exclude`. There is already an on-going PR which is...
When `@fastify/autoload` is loading the routes, these are not loaded through `vitest`'s Vite plugins. `nyc` has something called `istanbul-lib-hook` which might be related to this but as it does not...
With `istanbul-lib-hook` we are able to capture these require calls. But its API is synchronous which makes it difficult to work with asynchronous `vitenode.transformRequest`. ``` vitest::node/pool.ts: fetch "/src/app.ts" vitest::coverage-istanbul/src/provider.ts: onFileTransform...
So does that mean that other tooling can rely on `vitest` to handle code transforms of `require`'d files when `process.env.VITEST_WORKER_ID` is set? The logic on `@fastify/autoload` seems to expect so...
That seems to be the root cause. By manually changing `@fastify/[email protected]` to use dynamic `import()` instead of `require`, the files are picked and instrumented by Vitest correctly. ``` % Coverage...
That would still mean that projects would have to do the possible TS transform themselves, and in `require` we would only catch the transpiled code, right? In that case I...
@kylerush for now, if you could get the `@fastify/autoload` to use `await import()` instead of `require`, Vitest would do the TS transforming and coverage instrumentation correctly, out-of-the-box. As long as...
As a work-around for now you can use `@preserve` in the comment, e.g. ```diff -/* istanbul ignore if */ +/* istanbul ignore if -- @preserve */ if (condition) { ```...
If this is indeed coming from `esbuild` there is no way to fix this as they have stated not to support this. I think this is coming from `esbuild` since...
Thanks for the clarification @sheremet-va, that makes sense. > TypeScript is processed by esbuild. JavaScript is left untouched. Yes, it seems that in Javascript sources the comments are preserved. For...