Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jest 22 fails to report coverage on ts files #5109

Closed
KnisterPeter opened this issue Dec 18, 2017 · 24 comments
Closed

Jest 22 fails to report coverage on ts files #5109

KnisterPeter opened this issue Dec 18, 2017 · 24 comments

Comments

@KnisterPeter
Copy link

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
Copy link
Member

SimenB commented Dec 18, 2017

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

@KnisterPeter
Copy link
Author

@lovell
Copy link
Contributor

lovell commented Dec 18, 2017

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

@oliverzy
Copy link

oliverzy commented Dec 18, 2017

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
Copy link
Member

SimenB commented Dec 18, 2017

This is caused by #3458.

@felipeochoa ideas?

@SimenB
Copy link
Member

SimenB commented Dec 18, 2017

/cc @kulshekhar

@SimenB
Copy link
Member

SimenB commented Dec 18, 2017

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
Copy link
Contributor

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
Copy link
Member

SimenB commented Dec 18, 2017

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
Copy link
Contributor

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
Copy link
Member

SimenB commented Dec 18, 2017

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

@praxxis
Copy link

praxxis commented Dec 18, 2017

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

@SimenB
Copy link
Member

SimenB commented Dec 18, 2017

Closing then, sorry about that!

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

@attilacsanyi
Copy link

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
Copy link

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
Copy link
Member

SimenB commented Jan 31, 2018

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

@WhiteTurbine
Copy link

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
Copy link

adding to #5109 (comment):

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

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

@MartinWillitts
Copy link

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

@WhiteTurbine
Copy link

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

@benpolinsky
Copy link

benpolinsky commented Mar 5, 2018

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
Copy link

advntss commented Aug 14, 2018

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.

eezhal92 added a commit to eezhal92/tojem-web that referenced this issue Jan 21, 2019
@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests