Instrumenting does not work for component tests in Cypress v10 without Babel

[Alan Krygowski]

Logs and screenshots

   ⚠️ Could not find any coverage information in your application
            by looking at the window coverage object.
            Did you forget to instrument your application?
            See [code-coverage#instrument-your-application](https://github.com/cypress-io/code-coverage#instrument-your-application)
           `[@cypress/code-coverage]`
Cannot find coverage file [...]nyc_output/out.json
Skipping coverage report

Versions

• What is this plugin's version?
• ^3.10.0
• What is Cypress version?
• 10.6.0
• What is your operating system?
• MacOs
• What is the shell?
• Happens regardless of the shell
• What is the Node version?
• 14.17.2
• What is the NPM version?
• 6.14.13
• How do you instrument your application? Cypress does not instrument web application code, so you need to do it yourself.
• Followed both the guide in here, here and here
• When running tests, if you open the web application in regular browser, and open DevTools, do you see window.__coverage__ object? Can you paste a screenshot?
• Nope, its undefined for component tests. Prints the proper obj for normal
• Is there .nyc_output folder? Is there .nyc_output/out.json file. Is it empty? Can you paste at least part of it so we can see the keys and file paths?
• Not generated for component tests
• Do you have any custom NYC settings in package.json (nyc object) or in other NYC config files

•   'check-coverage': true,
    reporter: ['html', 'lcov'],
    include: [...],
    exclude: [...],
    branches: ...,
    lines: ...,
    functions: ...,
    statements: ...,```
  

• Do you run Cypress tests in a Docker container?
• Yes, but the issue happens outside too

Describe the bug
The code coverage does not work for component testing in v10 without Babel. When I run e2e tests the coverage shows fine. We cannot use babel due to issues outside my reach. I've tried following your tutorials on the browserify approach but it didn't give way. It looks like more of a lack-of edge case feature than something we could correct with config.

[Michał Kowalik]

Same issue on Cypress 12.8 + Create React App (TypeScript)

[Gustavo Souza]

Facing the same issue.

"cypress": "^12.3.0"

what I did:

1: Installed code-coverage

• yarn add -D @cypress/code-coverage

2: add to cypress/support/index.js file

• import '@cypress/code-coverage/support'

3: add to cypress/plugins/index.js file

module.exports = (on, config) => {
  require('@cypress/code-coverage/task')(on, config)
  return config
}

[Michail]

Also does not work with version 12 with babel.
Works with e2e tho.

What could be the issue? JSX?

[Michał Kowalik]

For the moment the workaround I applied was to downgrade cypress to 9.7.0. I'm using react-scripts with react-app-rewired so maybe this issue will be fixed when I switch to pure webpack based configuration

[Youngsun Yoo]

Has anyone fixed it without using react-script?

[Mike Plummer]

While Babel is definitely the easiest way to instrument your code it is not required for @cypress/code-coverage to work. A commonly-overlooked aspect of this plugin is that it does not instrument your code for you - that is your responsibility; Babel is just a convenient way to hook a tool like istanbul into the build process to generate instrumentation. However, it can be done manually by using nyc via command line, using something like istanbul-instrumenter-loader as a Webpack Config customization in your component testing config (or a corresponding Vite customization with vite-plugin-istanbul), or via an alternate compiler like SWC(example) as well, it's just a bit trickier.

I would recommend reaching out on Discord as there is likely someone else who has already tackled the same scenario. The majority of public examples do utilize Babel since it's the easiest way (by far!) but the tools linked above are all viable alternatives. As an aside for those asking, here is an example of getting code coverage working on e2e + CT on a CRA project using Typescript.

If anyone has a reproducible example of code coverage not working after after ensuring this plugin is configured properly and their code is being correctly instrumented we would be happy to troubleshoot. As-is, this does not appear to be either a defect or a feature request so I am going to close. Please comment with additional information and reproducible example if you disagree and feel this should remain open