-
Notifications
You must be signed in to change notification settings - Fork 91
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
could we make --all ignore comments #182
Comments
CC: @j03m. |
I did a bit of digging into this last night ... I wonder if it's worth the trouble, we end up going down the path of building a parser, and need to move around quite a bit of code in |
Yea, this isn't great. Looking at this, my current understanding is that we wouldn't have this issue for a file that is loaded, because in that case we're not manufacturing the coverage data? Is that correct? If that understanding is correct I think we could be more sophisticated. We could in theory use a parser like babylon or recast and parse the file into an AST and then walk the AST to generate the uncovered sections. This would be more expensive then the line stat we do today, but it would be much more accurate. What do you think? |
My current thinking, argue against it 😆, is that if you haven't loaded the file you haven't exercised the lines comprising comments ... so perhaps we're fine as is. |
Note that we had to manually exclude .d.ts files from the coverage runner, as they are only used during the transpile stage and never loaded at runtime. We use them to declare external modules and our own types. |
Will take a look at this. |
Just adding my 2 cents here, this also relates to files that only have Typescript interfaces. When executing the code with |
I'd love to have c8 be able to detect the usage of My barely-thought-out suggestion: only count actual runtime JS code in the covered or uncovered percentages. Other lines are treated as if they don't exist. That way large amounts of TS type definitions don't artificially pad or depress the numbers. |
So I had the exact same issue of |
Because our
--all
functionality does not take into account multi-line comments, we end up with a fairly large discrepancy betweennyc
andc8
's--all
, see:googleapis/nodejs-asset#236
I wonder if we could be clever and detect multiline comments, and drop these from our estimation of
--all
.The text was updated successfully, but these errors were encountered: