[Windows specific?] Running with nyc all=true causes all files to display as 0% coverage

[StevePavlin]

Logs and screenshots
Please provide debug logs by running Cypress from the terminal with DEBUG=code-coverage environment variable set, see the Debugging section of the README file.

Versions

• What is this plugin's version? If this is NOT the latest released version can you try the latest version, please? 3.5.1, tested with latest version as well.

• If the plugin worked before in version X, but stopped after upgrading to version Y, please try the released versions between X and Y to see where the breaking change was. N/A

• What is Cypress version? 4.4.0

• What is your operating system? Windows 10

• What is the shell? Git bash/cywin

• What is the Node version? 12.4.0

• What is the NPM version? 6.9.0

• How do you instrument your application? Cypress does not instrument web application code, so you need to do it yourself. https://github.com/cypress-io/instrument-cra

• 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? Its displaying correctly. https://pastebin.com/0Mn92t3H

• 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? There's an .nyc_output folder and out.json file. Pasted one for each flag (true & false in example section.)

• Do you have any custom NYC settings in package.json (nyc object) or in other NYC config files https://github.com/penx/storybook-code-coverage/blob/master/package.json

• Do you run Cypress tests in a Docker container? No

Describe the bug
When running a coverage report with the all flag set to true within nyc in package.json, the reporter is showing all files at 0% coverage, but it shows correct coverage at the aggregate/top level.

Additional info to replicate: The bug is resolved and correct file level coverage is displayed when I set all to false in that repository.

Link to the repo
https://github.com/penx/storybook-code-coverage is how I double checked that this is a bug, I also tested with the latest version of cypress and the cra/this plugin on another project.

Example
After opening the coverage report in coverage/integration/lcov-report/index.html in that that repository after running npm run coverage:

When all=false (working):

Top level coverage: https://gyazo.com/eeab9d1a76edf98a7670168c41c0b788
File coverage: https://gyazo.com/a72045d928476dfa96e1d6f991ff204c
out.json: https://pastebin.com/xm83Q1mX

When all=true (broken)

Top level coverage: Same as all=false
File coverage: https://gyazo.com/b8cbb29228c2afb7ac5d1ea125c369cf (notice how this file was noted as 100% covered in the top level.)
out.json: https://pastebin.com/xuM6yXrF

This bug must be windows specific with the all flag, as @penx wrote an article about his repository which show it correctly working in a unix environment: https://github.com/penx/storybook-code-coverage
https://dev.to/penx/combining-storybook-cypress-and-jest-code-coverage-4pa5

[StevePavlin]

Can confirm this is most likely a windows bug in either code-coverage or instrument-cra causing the file-based coverage to display incorrectly, aggregate coverage is being reported correctly in our CI when sending out.json to codecov.

[RichardMatsen]

Please see Angular + Cypress code coverage reporting not working for some diagnosis of this problem. The problem seems to relate to [PR 208] where additional coverage nodes are added to satisfy the all=true flag.

The original coverage nodes have back-slashes in the path, where-as the added (empty) nodes have forward slashes. I recall the paths were "normalized" to forward-slashes when saving in earlier releases, but this seems to be broken now.

[RichardMatsen]

A potential fix can be applied here

const coveredPaths = coverageKeys.map(key => nycCoverage[key].path)
  .map(path => path.replace(/\\/g, '/'))  // Compare "normalized" paths

[mzellho]

...a little late to the party, just to confirm that what @RichardMatsen mentioned above (path.replace) helped me out on a Windows environment as well. good enough for a workaround.