Skip to content
This repository has been archived by the owner on Dec 8, 2024. It is now read-only.

Highlighting Incorrect in Babel ES2015 Code #557

Open
cphoover opened this issue Mar 3, 2016 · 6 comments
Open

Highlighting Incorrect in Babel ES2015 Code #557

cphoover opened this issue Mar 3, 2016 · 6 comments

Comments

@cphoover
Copy link

cphoover commented Mar 3, 2016

When running coverage against babel es2015 source code, highlighting is completely off.

It seems to start perhaps in the correct position, but the end of the highlighting is off.

Here is an annotated screenshot of the issue:
http://imgur.com/xXFWjtp

@skozin
Copy link

skozin commented Mar 20, 2016

I've the same issue. Highlighting is incorrect when using Babel 6.5 to transpile ES2015 to ES5, and even ES5 to ES5 (i.e. running Babel over already compiled sources). Example:

image

image

@cphoover
Copy link
Author

@skozin as a temporary solution... I changed the css so that .no-branch has a left border of 10px solid red... instead of a background color... This way you only see highlighting at the start of the missed coverage.

hacky but works.

@skozin
Copy link

skozin commented Mar 25, 2016

@cphoover, thanks, interesting hack. I'll try it =)

BTW, I've found that, in my case, the issue is probably related not to istanbul itself, but to nyc, which is a coverage tool built on istanbul that works for apps with subprocesses. See this issue: istanbuljs/nyc#198.

@julkue
Copy link

julkue commented Mar 31, 2016

I also advocate that Babel's workaround code will not be tested. Example:
example

@skozin
Copy link

skozin commented Mar 31, 2016

@julmot, +1, but probably the only way to do this is to use info from sourcemaps to see whether the specific part of generated code maps to some location in the sources, and exclude it from report if not (i.e. don't highlight it and don't count in covered/total functions/branches/statements/lines numbers).

Probably this can be done only on function level, as Babel only generates helpers in form of functions. On the other hand, Babel uses regenerator to transpile generators and async/await functions, and regenerator produces statements that cannot be mapped to the original source.

But I would be happy even if Istanbul covered only the non-generator case.

See also: #582, istanbuljs/nyc#198 (comment).

jbinto added a commit to jbinto/frig that referenced this issue Apr 13, 2016
* Add npm script `cover`, which calls istanbul:
  * Do not execute `istanbul` via `babel-node`, this is deprecated, instead use `babel-register` as an argument to `mocha` (credit: gotwarlost/istanbul#594 (comment))
  * Use `--root src/` to fix issue where istanbul also attempts to cover `mocha` (credit: douglasduteil/isparta#68 (comment))
  * Use `--include-all-sources` to make the coverage percentages actually meaningful by including sources that didn't get executed

* In `src/higher_order_components/errors_normalizer.js`, make minor change to return statement. This form: `if (foo) return { a: 'b' }` seems to have confused Istanbul's coverage highlighter. There are other cases like this, that are bugs in Istanbul (e.g. gotwarlost/istanbul#557). Probably worth making a repro case for this and reporting to them.
jbinto added a commit to jbinto/frig that referenced this issue Apr 13, 2016
* Add npm script `cover`, which calls istanbul:
  * Do not execute `istanbul` via `babel-node`, this is deprecated, instead use `babel-register` as an argument to `mocha` (credit: gotwarlost/istanbul#594 (comment))
  * Use `--root src/` to fix issue where istanbul also attempts to cover `mocha` (credit: douglasduteil/isparta#68 (comment))
  * Use `--include-all-sources` to make the coverage percentages actually meaningful by including sources that didn't get executed

* In `src/higher_order_components/errors_normalizer.js`, make minor change to return statement. This form: `if (foo) return { a: 'b' }` seems to have confused Istanbul's coverage highlighter. There are other cases like this, that are bugs in Istanbul (e.g. gotwarlost/istanbul#557). Probably worth making a repro case for this and reporting to them.
@toddpi314
Copy link

@cphoover Agreed. This appears to just be proble with utilizing the background css attribute and the container structure. If you favor border vs background the correct areas are highlighted

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants