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

100% line coverage when 50% at most with ESM #34

Open
jdalton opened this issue Sep 21, 2018 · 23 comments
Open

100% line coverage when 50% at most with ESM #34

jdalton opened this issue Sep 21, 2018 · 23 comments
Assignees
Labels
bug help wanted Issue is well defined but needs assignment

Comments

@jdalton
Copy link

jdalton commented Sep 21, 2018

I'm filing at the request of @bcoe. The bug may actually be in v8-to-istanbul.

To repro npm i -g c8 esm nyc

Then create a file foo.js:

const { log } = console

function a() {
  if (true) {
    log("hi")
  } else {
    log("false")
  }
}

function b() {
  if (true) {
    log("hi")
  } else {
    log("false")
  }
}

a()

and run c8 node foo.js which will report:

hi
----------|----------|----------|----------|----------|-------------------|
File      |  % Stmts | % Branch |  % Funcs |  % Lines | Uncovered Line #s |
----------|----------|----------|----------|----------|-------------------|
All files |       55 |       75 |        0 |       55 |                   |
 foo.js   |       55 |       75 |        0 |       55 |... 13,14,15,16,17 |
----------|----------|----------|----------|----------|-------------------|

now change the line const { log } = console to import { log } from "console"
and run c8 node -r esm foo.js which will report:

hi
----------|----------|----------|----------|----------|-------------------|
File      |  % Stmts | % Branch |  % Funcs |  % Lines | Uncovered Line #s |
----------|----------|----------|----------|----------|-------------------|
All files |      100 |      100 |      100 |      100 |                   |
 foo.js   |      100 |      100 |      100 |      100 |                   |
----------|----------|----------|----------|----------|-------------------|

If I run nyc node -r esm foo.js instead it will report:

hi
----------|----------|----------|----------|----------|-------------------|
File      |  % Stmts | % Branch |  % Funcs |  % Lines | Uncovered Line #s |
----------|----------|----------|----------|----------|-------------------|
All files |    42.86 |       25 |       50 |    42.86 |                   |
 foo.js   |    42.86 |       25 |       50 |    42.86 |        7,12,13,15 |
----------|----------|----------|----------|----------|-------------------|

and with report --reporter=html is

@bcoe
Copy link
Owner

bcoe commented Sep 22, 2018

@danieldiekmeier you've hit the nail on the head, the problem is that we're not taking into account the wrapper that's injected before executing ESM code. A similar problem to the first issue pointed out here:

nodejs/node#22919

would love help digging into this; for starters we could allow he header length to be configured in c8 ... this feels like a fragile long-term solution though, and I was unable to find common ground in the Node.js internal modules (the prefix injected into the code seems to vary).

@bcoe bcoe added help wanted Issue is well defined but needs assignment bug labels Sep 22, 2018
@danieldiekmeier
Copy link

Maybe sourcemaps could help? I'm not too familiar with how istanbul/nyc do it, but I think they can work backwards from sourcemaps to show the coverage of your original source code?

@jdalton
Copy link
Author

jdalton commented Sep 24, 2018

If sourcemaps are the answer I can provide inline sourcemaps or if some other c8 specific metadata is needed I can do that too.

@matthewmueller
Copy link

Quick question: is this a bug in the V8 implementation or in userland?

@bcoe bcoe changed the title 100% line coverage when 50% at most. 100% line coverage when 50% at most with ESM Jul 17, 2019
@bcoe
Copy link
Owner

bcoe commented Jul 17, 2019

@matthewmueller is your issue also ESM related? in this case it's a little bit of both:

  • source maps aren't yet well supported in V8 and Node.js.
  • but, we should be able to work with @jdalton to add them to ESM potentially, in such a way that c8 can interpret them.

@matthewmueller
Copy link

matthewmueller commented Jul 17, 2019

Ah, I hadn't realized this issue was ESM-specific, but that's still a very interesting summary of the current state of affairs. Thanks!

@GMartigny
Copy link

I updated the minimal reproduction repo for this issue with the last version of c8 and esm, but still no luck.
@jdalton does it's still in the work ? Can we help on that ?

@bcoe
Copy link
Owner

bcoe commented Oct 24, 2019

@jdalton, @GMartigny, and company, with recent work in Node.js, related to source-maps, as of Node 13, we can now support source-maps that are added during in-memory transpilation, see:

#152

I would love to add a similar test for ESM, and close this ticket.

@j03m j03m self-assigned this Nov 29, 2019
@j03m
Copy link
Collaborator

j03m commented Nov 29, 2019

Grabbing this will try to tackle

@JohnHardy
Copy link

Did you have any luck with this?

@StreetStrider
Copy link

I'm using esm and I've tried switch to c8 because I got some issues with nyc + esm previously. Everythings seems to work OK, however, today I've noticed that in one of esm + c8 projects I got 100% coverage, even when I add brand new code which is cannot be covered from start.

@bcoe
Copy link
Owner

bcoe commented May 4, 2020

@StreetStrider @JohnHardy we would still need to do a bit of work to make ESM and c8 source map support work together appropriately I believe.

@chrisveness
Copy link

In Node.js v13.2.0+ ES-modules is available without the --experimental-modules flag, and applications will run without the esm package: I have found that c8 works well using the native Node.js loader if v13.2.0+ can be used.

@j03m
Copy link
Collaborator

j03m commented May 7, 2020

Apologies, I have been working on other issues :(

@Real-John-Cheung
Copy link

hmm any updates on this?
I got very confusing result like this
螢幕截圖 2021-04-08 下午9 49 41

And I think it might be caused by the same problem (In the above case I guess that the uncover branches are actually from the 'if's )...
I wonder if there is any short-term trick that I can do to solve this temporarily (guessing where the actual problem is is hard)...
On macOS Catalina with Node version 14.15.4, c8 version 7.7.1

@Swivelgames
Copy link

Any update on this?

I wouldn't press so hard, but this bug effectively renders c8 useless. Code coverage for ESM modules at this point is bit completely broken. The metrics are effectively useless given how off the numbers are that its reporting for ESM modules. More and more projects are moving to ESM, especially given that it's been available since Node 12, and Node 20 is expected to be released in a month.

Any traction on this at all would be superb! 🤞

@Swivelgames
Copy link

@danieldiekmeier Given that this is still an issue even with native ES Modules, has discussion, history, and watchers, and its still open, I don't see how it would be useful to create multiple issues when this one already exists.

However, if you're not experiencing issues with it, I would recommend you Unsubscribe from the topic so that you're not bothered by future notifications 🙂

@araujoarthur0
Copy link

Are there any updates to this?

sverweij added a commit to sverweij/virtual-code-owners that referenced this issue May 11, 2024
## Description

- removes c8 dependency &  config
- uses  the --experimental-test-coverage cli switch to get coverage
- updates `./tools/dot-with-summary.reporter.js` reporter to emit
coverage information
- updates the ci workflow to emit information from that report instead
of the markdown derived from the codecov run (on node 20 only for now as
there it's stable).

## Motivation and Context

In our setup c8 doesn't provide any real coverage information anymore
(see below - note the number of lines, functions and branches). Root
cause probably lies [how node handles ESM/ how v8-to-istanbul can
process that](bcoe/c8#34). As nodejs now also
has a --experimental-test-coverage built in we migrate this to that.

> --experimental-test-coverage isn't perfect either b.t.w. In node 20
it's stable, but on node 22 (at least in our set up) it tends to report
different results on each run with unchanged source code.

<details>
<summary>recent c8 output on virtual-code-owners main branch</summary>


```shell
$ npm test

> virtual-code-owners@8.0.5 test
> c8 tsx --test-reporter ./tools/dot-with-summary.reporter.js --test src/*.test.ts src/**/*.test.ts

.....................................................

53 passing (1.159 ms)


=============================== Coverage summary ===============================
Statements   : 100% ( 11/11 )
Branches     : 100% ( 0/0 )
Functions    : 100% ( 0/0 )
Lines        : 100% ( 11/11 )
================================================================================
```

</details>


## How Has This Been Tested?

- [x] green ci
- [x] manually (the script in tools should probably be put in a separate
repo and get its own set of unit tests c.s., but for fixing the issue at
hand a bit out of scope.

## Screenshots

```
.....................................................

53 passing (1.199 ms)

=============================== Coverage summary ===============================
Branches     : 100 % (205/205)
Functions    : 100 % (123/123)
Lines        : 100 % (1.533/1.533)
================================================================================
```

With uncovered lines/ functions (b.t.w. same, unchanged codebase as
above ..., but using node 22, after a run or two)

```shell
.....................................................

53 passing (1.216 ms)

=============================== Coverage summary ===============================
Branches     : 100 % (184/184)
Functions    : 98,31 % (116/118) NOK
Lines        : 99,74 % (1.529/1.533)
================================================================================

Uncovered lines:
  /Users/sander/prg/js/virtual-code-owners/src/labeler-yml/generate.ts:102,103,104
  /Users/sander/prg/js/virtual-code-owners/src/virtual-code-owners/anomalies.ts:40

Uncovered functions:
  /Users/sander/prg/js/virtual-code-owners/src/virtual-code-owners/anomalies.ts:40,40
```

## Types of changes

<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] Documentation only change
- [ ] Refactor (non-breaking change which fixes an issue without
changing functionality)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Chore (thing that needs doing in e.g. coding infrastructure)
sverweij added a commit to sverweij/virtual-code-owners that referenced this issue May 11, 2024
## Description

- removes c8 dependency &  config
- uses  the --experimental-test-coverage cli switch to get coverage
- updates `./tools/dot-with-summary.reporter.js` reporter to emit
coverage information
- updates the ci workflow to emit information from that report instead
of the markdown derived from the codecov run (on node 20 only for now as
there it's stable).

## Motivation and Context

In our setup c8 doesn't provide any real coverage information anymore
(see below - note the number of lines, functions and branches). Root
cause probably lies [how node handles ESM/ how v8-to-istanbul can
process that](bcoe/c8#34). As nodejs now also
has a --experimental-test-coverage built in we migrate this to that.

> --experimental-test-coverage isn't perfect either b.t.w. In node 20
it's stable, but on node 22 (at least in our set up) it tends to report
different results on each run with unchanged source code.

<details>
<summary>recent c8 output on virtual-code-owners main branch</summary>

```shell
$ npm test

> virtual-code-owners@8.0.5 test
> c8 tsx --test-reporter ./tools/dot-with-summary.reporter.js --test src/*.test.ts src/**/*.test.ts

.....................................................

53 passing (1.159 ms)

=============================== Coverage summary ===============================
Statements   : 100% ( 11/11 )
Branches     : 100% ( 0/0 )
Functions    : 100% ( 0/0 )
Lines        : 100% ( 11/11 )
================================================================================
```

</details>

## How Has This Been Tested?

- [x] green ci
- [x] manually (the script in tools should probably be put in a separate
repo and get its own set of unit tests c.s., but for fixing the issue at
hand a bit out of scope.

## Screenshots

```
.....................................................

53 passing (1.199 ms)

=============================== Coverage summary ===============================
Branches     : 100 % (205/205)
Functions    : 100 % (123/123)
Lines        : 100 % (1.533/1.533)
================================================================================
```

With uncovered lines/ functions (b.t.w. same, unchanged codebase as
above ..., but using node 22, after a run or two)

```shell
.....................................................

53 passing (1.216 ms)

=============================== Coverage summary ===============================
Branches     : 100 % (184/184)
Functions    : 98,31 % (116/118) NOK
Lines        : 99,74 % (1.529/1.533)
================================================================================

Uncovered lines:
  /Users/sander/prg/js/virtual-code-owners/src/labeler-yml/generate.ts:102,103,104
  /Users/sander/prg/js/virtual-code-owners/src/virtual-code-owners/anomalies.ts:40

Uncovered functions:
  /Users/sander/prg/js/virtual-code-owners/src/virtual-code-owners/anomalies.ts:40,40
```

## Types of changes

<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] Documentation only change
- [ ] Refactor (non-breaking change which fixes an issue without
changing functionality)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Chore (thing that needs doing in e.g. coding infrastructure)
sverweij added a commit to sverweij/virtual-code-owners that referenced this issue May 11, 2024
## Description

- removes c8 dependency &  config
- uses  the --experimental-test-coverage cli switch to get coverage
- updates `./tools/dot-with-summary.reporter.js` reporter to emit
coverage information
- updates the ci workflow to emit information from that report instead
of the markdown derived from the codecov run (on node 20 only for now as
there it's stable).

## Motivation and Context

In our setup c8 doesn't provide any real coverage information anymore
(see below - note the number of lines, functions and branches). Root
cause probably lies [how node handles ESM/ how v8-to-istanbul can
process that](bcoe/c8#34). As nodejs now also
has a --experimental-test-coverage built in we migrate this to that.

> --experimental-test-coverage isn't perfect either b.t.w. In node 20
it's stable, but on node 22 (at least in our set up) it tends to report
different results on each run with unchanged source code.

<details>
<summary>recent c8 output on virtual-code-owners main branch</summary>

```shell
$ npm test

> virtual-code-owners@8.0.5 test
> c8 tsx --test-reporter ./tools/dot-with-summary.reporter.js --test src/*.test.ts src/**/*.test.ts

.....................................................

53 passing (1.159 ms)

=============================== Coverage summary ===============================
Statements   : 100% ( 11/11 )
Branches     : 100% ( 0/0 )
Functions    : 100% ( 0/0 )
Lines        : 100% ( 11/11 )
================================================================================
```

</details>

## How Has This Been Tested?

- [x] green ci
- [x] manually (the script in tools should probably be put in a separate
repo and get its own set of unit tests c.s., but for fixing the issue at
hand a bit out of scope.

## Screenshots

```
.....................................................

53 passing (1.199 ms)

=============================== Coverage summary ===============================
Branches     : 100 % (205/205)
Functions    : 100 % (123/123)
Lines        : 100 % (1.533/1.533)
================================================================================
```

With uncovered lines/ functions (b.t.w. same, unchanged codebase as
above ..., but using node 22, after a run or two)

```shell
.....................................................

53 passing (1.216 ms)

=============================== Coverage summary ===============================
Branches     : 100 % (184/184)
Functions    : 98,31 % (116/118) NOK
Lines        : 99,74 % (1.529/1.533)
================================================================================

Uncovered lines:
  /Users/sander/prg/js/virtual-code-owners/src/labeler-yml/generate.ts:102,103,104
  /Users/sander/prg/js/virtual-code-owners/src/virtual-code-owners/anomalies.ts:40

Uncovered functions:
  /Users/sander/prg/js/virtual-code-owners/src/virtual-code-owners/anomalies.ts:40,40
```

## Types of changes

<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] Documentation only change
- [ ] Refactor (non-breaking change which fixes an issue without
changing functionality)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Chore (thing that needs doing in e.g. coding infrastructure)
@nwoolls
Copy link

nwoolls commented May 13, 2024

From what I can tell both c8 and Nyc are broken if the source under test makes use of ESM. Is that correct? Is there any form of coverage collection that works when using ESM?

@StreetStrider
Copy link

@nwoolls I've been using nyc + ts-mocha and it reports proper numbers for my project.

@nwoolls
Copy link

nwoolls commented May 13, 2024

@StreetStrider thanks very much for that info & direction. I pushed further down that path and got it working. The issue I had run into with that direction ended up being with Chai (chaijs/chai#1568).

@StreetStrider
Copy link

@nwoolls I had something similar. I think this is due to chai v5 ESM migration. I decided to stick with v4, maybe for an extended time. Chai CJS has been serving me for years without problems, so why should I push to the new version when v4 does the job. Besides, it is a testing infrastructure, so no risks or vulnerabilities for the user.

@nwoolls
Copy link

nwoolls commented May 14, 2024

@StreetStrider that's the direction I took as well 👍🏻.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug help wanted Issue is well defined but needs assignment
Projects
None yet
Development

No branches or pull requests