6.56 MB install size

[jaydenseric]

c8 has a huge 6.56 MB install size:

https://packagephobia.now.sh/result?p=c8

With 97 modules in the dependency graph:

https://npm.anvaka.com/#!/view/2d/c8

It is surprising how heavy this package is, considering v8 does all the heaving lifting and it mostly just needs to display a report. Is this something that can be improved upon, are there low hanging fruit?

handlebars (4.42 MB) jumps out.

From a complexity perspective, could the v8 coverage data could be reported directly, without a conversion process to the instanbul format?

[SimenB]

Handlebars has been removed from beta version of istanbul, which was upgraded in #168. You're waiting for #170

[bcoe]

We need to convert to a line based representation to apply source maps any ways. Not to mention it would be a huge amount of work to port istabul's dozen or so reports.

6MB is a fairly small install size for a developer tool, and it sounds like that drops a lot with handlebars being removed 😜

[jaydenseric]

6MB is a fairly small install size for a developer tool

Agree to disagree. The bar is simply set unbelievably low with tap being 84 MB, and jest being 32 MB.

I'm looking at creating a CLI from scratch for reporting Node.js v8 coverage data; it should only be a few KB.

[bcoe]

The devil is in the details, a lot of modern codebases rely on source-maps; so you are going to want a conversion step. I would look at Node.js' sourcemap library potentially if you want to trim down the size of the library.

The next challenge will be reporting, I think there's not a huge amount of value in remaking all of Istanbul's reports, but would be curious to see the experiment.

I closed this because I don't think there's much actionable, beyond this being a different library.

[jaydenseric]

@bcoe I just published coverage-node after about 2 weeks of work, and it only has 2 dependencies for a 304 kB install size:

• https://npm.anvaka.com/#!/view/2d/coverage-node
• https://packagephobia.now.sh/result?p=coverage-node

It only has around 240 source lines of code, so the vast majority of the install size comes from the @bcoe/v8-coverage dependency, which unfortunately has a 271 kB install size:

https://packagephobia.now.sh/result?p=%40bcoe%2Fv8-coverage

I tried for about 3 days to do my own merging of V8 code coverage data from multiple processes, but found many bugs and mysteries (very little docs) around what exactly makes function coverage isBlockCoverage. Once I understand it better and V8 is less buggy I'll take another stab.

The devil is in the details, a lot of modern codebases rely on source-maps; so you are going to want a conversion step. I would look at Node.js' sourcemap library potentially if you want to trim down the size of the library.

Thanks for the tip, although source map support is not a feature I need for now.

I'm really happy about the CLI/API and how the reports look (much better DX IMO)…

Very sad that V8 coverage data is really only reliable enough to use from Node.js v13.3+. This means it can't really be used on most of the packages I maintain. Looking forward to the day Node.js < v13 can be dumped; native coverage and ESM FTW.

[bcoe]

@jaydenseric 👍

I tried for about 3 days to do my own merging of V8 code coverage data from multiple processes, but found many bugs and mysteries (very little docs) around what exactly makes

Yes, my first implementation of this was terrible and Node.js' merging process, which involved merging 1000s of reports took 30 minutes. @demurgos did an incredible job with this algorithm.

It only has around 240 source lines of code, so the vast majority of the install size comes from the @bcoe/v8-coverage dependency, which unfortunately has a 271 kB install size:

Mind listing the install size of c8@next, and potentially nyc@next on your package's README?

https://packagephobia.now.sh/result?p=c8@7.0.0-candidate.0

As @SimenB mentions, a good chunk of the install size is handlebars, so the packages are a bit smaller than you draw attention to.

I'll have next moved to latest midway through this week.

Very sad that V8 coverage data is really only reliable enough to use from Node.js v13.3+

I'm glad to have another person debugging V8 and filing issues. I'm actually feeling fairly positive, because it's taken two years to get to the point where V8's coverage is comprehensive enough to consider.