Server-side coverage is not tracked

[romandecker]

Hey!

Thanks for putting this together, I was able to adopt it for my project ❤️

However, I found that some files don't seem to be tracked, specifically anything that runs server-side. In my project, I have middlewares, api routes, getServerSideProps, etc... and all of that is not being tracked.

I've put together a minimum example with a single getServerSideProps call.

I made sure to explicitly include the file I want to cover in the .nycrc.json file, however, code in no-coverage-here is not being tracked as you can see:

An interesting side note seems to be, that there invocation of foo() seems to be tracked correctly, it's really just the file inside no-coverage-here that's missing.

Any idea what could be going wrong here?

[kylemh]

No idea here! 😞

I looked for a relevant issue in https://github.com/cypress-io/code-coverage but didn't see any. It's possible this could be a mistake from Cypress's code-coverage module, from Istanbul, or from some aspect of the config written here.

If you find the answer, let's definitely fix it here.

[romandecker]

I'll report it with them.

[kylemh]

The problem could be here, to be clear. I just don't see where.

[cri-us]

Same issue, any update about solution ?

[kylemh]

@bahmutov let me know if you have any ideas that I can act on - even if it's just high level thoughts. Would love to keep this repo working well and I can do a Cypress v10 update

[jpierson-at-riis]

Just running into this issue myself. I've been tracing through why our layout.jsx file shows no coverage on SonarQube which led me to our generated lcov.info file which seems to have no mention of layout.jsx. After reasoning this through I came to the conclusion that the way that we are collecting coverage through Jest and CypressJS that only client side coverage is being gathered. For our site we are using NextJS for it's SSG capabilities with the majority of the app using CSR for a typical SPA like experience.

Thinking this through, server side code runs at build time with SSG or at runtime with SSR would need to generate coverage data and either make it available in a separate file output or it would need to be tacked into the client side coverage data as soon as the page loads. Has there been any thoughts on which of these approaches would be appropriate or even feasible? Getting this to work for the dev server would be useful too and happens to be the way that we are collecting coverage data currently in our build pipeline through CypressJS.

My only workaround that I can think of for now is to disable coverage for all code that runs through SSG or SSR but identifying all of this code is not as simple as looking at a simple file name pattern or location of the code because of how code organized in a Next.js project with server side and client side code comingled and somewhat dynamically determined depending on the specific runtime scenario (ex. dev server vs. production build using export).

[kylemh]

I've wondered if it's possible to abuse OpenTelemetry and the experimental Vercel instrumentation hook to provide server-side and build-time coverage; however, it sounds like in https://github.com/cypress-io/code-coverage/issues/557#issuecomment-2334192181 you figured out how to use the swc instrumentation plugin to get more comprehensive instrumentation? Would love a PR to this repo on how you've set that up!

I did see https://github.com/mike-plummer/nextjs-cypress-ct-example here though

[jwickens]

I'm not using cypress and I'm running into this issue when trying to collect coverage via nyc next dev. Frustratingly it shows that that it read things like src/pages/home/index.js but didn't execute any of the functions. Maybe next's server is spawning a new process to execute the page for server rendering?

Edit: opened a feature request here: https://github.com/vercel/next.js/discussions/70713