Jest 22 fails to report coverage on ts files

[KnisterPeter]

Do you want to request a feature or report a bug?
A bug

What is the current behavior?
Coverage reporting fails

If the current behavior is a bug, please provide the steps to reproduce and
either a repl.it demo through https://repl.it/languages/jest or a minimal
repository on GitHub that we can yarn install and yarn test.

What is the expected behavior?
Collect coverage information.

Please provide your exact Jest configuration and mention your Jest, node,
yarn/npm version and operating system.

We are right now using Jest 21 with ts-jest. When updating to Jest 22 it fails to report coverage.
The output by jest is:

PASS src/text-input/index.style.test.tsx
FAIL src/text-input/index.style.test.tsx
  ● Test suite failed to run

    No file coverage available for: /x/x/x/src/text-input/index.style.test.tsx
      
      at CoverageMap.fileCoverageFor (node_modules/istanbul-lib-coverage/lib/coverage-map.js:96:15)
      at Array.forEach (native)

[SimenB]

Can you create a repo which works on jest 21 and fails on jest 22?

[JounQin]

https://travis-ci.org/JounQin/vue-translator/builds/318083368?utm_source=github_status&utm_medium=notification

[KnisterPeter]

Here we have it: https://github.com/KnisterPeter/jest-typescript-coverage-failure

[lovell]

Perhaps the ts-jest preprocessor will need to be updated to handle breaking API changes first?

[oliverzy]

The similar error happened using Jest 22 with jest-vue-preprocessor.
The setup is okay for Jest 21 as well.

PASS  src/components/icon/__test__/icon.spec.js
 FAIL  src/components/icon/__test__/icon.spec.js
  ● Test suite failed to run

    No file coverage available for: /Users/zhouyujie/dev/xxx/xxx/src/components/icon/__test__/icon.spec.js

      at CoverageMap.fileCoverageFor (node_modules/istanbul-lib-coverage/lib/coverage-map.js:96:15)
          at Array.forEach (<anonymous>)

[SimenB]

This is caused by #3458.

@felipeochoa ideas?

[SimenB]

/cc @kulshekhar

[SimenB]

All lies in this post, I was fooled by caching...

Updating `ts-jest` to return the sourcemap directly seems to fix the issue.

While this means that ts-jest probably can be simplified, we shouldn't break it.

Diff "fixing" the issue:

diff --git c/src/transpile-if-ts.ts w/src/transpile-if-ts.ts
index 6339e76..ac8b0f7 100644
--- c/src/transpile-if-ts.ts
+++ w/src/transpile-if-ts.ts
@@ -11,7 +11,7 @@ export function transpileIfTypescript(path, contents, config?) {
       fileName: path,
     });
 
-    return transpiled.outputText;
+    return { code: transpiled.outputText, map: transpiled.sourceMapText };
   }
   return contents;
 }

[felipeochoa]

I'm not sure how the coverage reporter works, but maybe this change is causing a different code path to run? If I recall correctly, instrument was not necessarily true with the --coverage flag.

[SimenB]

Good catch, rolling back the change in that line makes tests pass. That change in and of itself seems sane though, doesn't it?

Do you think you could send a PR with an integration test for the coverage, btw? Seems like we forgot it even though you had it as a checkbox in your PR.

[felipeochoa]

Yeah not sure what happened there. I unfortunately don't have time to dive into this right now to figure out the fix, but may be able to after the new year, sorry!

[SimenB]

A patch 22.0.1 has been released, could you please try that?

[praxxis]

@SimenB I was seeing the same problems as the original reporter and they are now fixed in 22.0.1 👍

[SimenB]

Closing then, sorry about that!

Help would be much appreciated in #5121 if anybody has any bright ideas 🙂

[attilacsanyi]

I use jest-preset-angular and the following config solved the issue to me in package.json:

"jest": {
...
    "coveragePathIgnorePatterns": [
      "/node_modules/",
      "index.ts"
    ]
...
}

Thanks for this forum.

[WhiteTurbine]

Please re-open - bug still exists:

#5109

Issue remains in the newest version of Jest at a time (22.1.4). Last working version I found was 21.2.1. This issue can be reproduced only on Windows.

Jest is registering same file to Istanbul-lib-coverage twice with path that only differs in case (“c:/” vs “C:/”). This makes Istambul add file twice using “addFileCoverage” method. As a result coverage report shows 2 files instead of 1. In addition to showing 2 files, it is not able to find one of the paths in its internal array of coverage information (this.data) using “fileCoverageFor” method because file addresses there are case sensitive.

I have worked-around the issue by overriding “istanbul-lib-coverage” slightly using “override-require” node module. However, proper fix should probably be in Jest and this requires further investigation.

[SimenB]

@WhiteTurbine mind opening a separate issue? Including a reproduction, I highly doubt it's the same issue.

[WhiteTurbine]

I have in fact opened #5428. Cause might be different but symptoms are identical as in initial comment of this ticket. This is why I asked to re-open.

It might be challenging for me to provide easy way to reproduce because it seems to be slightly intermittent issue. Me and my colleagues had issue appear and disappear on same console when tests were run multiple times. We used runInBand single thread execution, coverage enabled, TypeScript.

However, I do have something nearly as good. I spent a day, debugged and know exactly what causes the issue in the end - also several ways to sort it out (tested multiple times to confirm the cause and work-around).

Problem is that drive letter (i.e c:/) arrives in different cases sometimes (c:/ and C:/). Istambul stores path in object as keys and therefor it does not match the path correctly if cases suddenly differ. Solution is to use consistent case for drive letters.

I worked problem around by injecting code into Istambul which manually compares keys in lower case with provided path in lower case before running original code. If such work-around is used, this must only be done for Windows platform since in Linux case matters a lot!

However, I would recommend to normalize paths on Jest side and not leave this to other plugins to prevent weird issues like this.

[jfairley]

adding to #5109 (comment):

I use angular playground, so adding the following to my jest config fixed me.

    "coveragePathIgnorePatterns": [
      "/node_modules/",
      "/playground/"
    ]

[MartinWillitts]

I was seeing something matching this and changed the filename from camel case to all lower case and the problem went away.

[WhiteTurbine]

@MartinWillitts , I think you saw same issue since hack I did was I lowercased paths in istambul coverage plugin.

[benpolinsky]

For others encountering this issue via google search results, please check that the file referenced in the error message is always referenced in your app using the correct casing.

In my case, I was importing a component with a lowercase name, yet the file was uppercased. Changing the casing of the file fixed the problem.

I am on Windows as well.

[advntss]

In my case the same issue was caused because tests were run under cygwin. Someday cygwin console glitched and all tests showed that error until I restarted cygwin console.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.