This repository has been archived by the owner on Jan 19, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 63
Wrong coverage output with Babel #86
Comments
Can confirm switching to |
I'm seeing a similar problem with the number of lines being affected by the combination of babel-loader and istanbul-instrumenter-loader. https://github.com/webpack-contrib/istanbul-instrumenter-loader#with-babel suggests |
foolip
added a commit
to GoogleChromeLabs/confluence
that referenced
this issue
May 15, 2019
This was referenced May 15, 2019
I've tried both post and pre now: As expected, |
foolip
added a commit
to GoogleChromeLabs/confluence
that referenced
this issue
May 15, 2019
Currently instrumentation is running after babel, which results in incorrect and nonsensical coverage information. The node vs. web coverage here is an example: https://codecov.io/gh/GoogleChromeLabs/confluence/src/f6802df5a6be89042a1db1e7b82f0a0a90906caf/lib/dao/indexed_dao.es6.js This could be fixed by changing the order: #404 However, it's not clear if that's correct: webpack-contrib/istanbul-instrumenter-loader#86 There's no need to run Babel to test stable versions of Chrome or Firefox, so just skip babel-loader.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
this is my webpack configuration in karma.conf.js:
html reporter result:
instrumented file like this:
if I update my webpack configuration, and run the instrumentation as a
per
step.everything is ok.
The text was updated successfully, but these errors were encountered: