Update the compared c8 install size in the readme

[bcoe]

First off, especially given that you rely on dependencies that I wrote, I find it a little frustrating that you go out of your way to criticize the install size of nyc and c8 in your documentation ... but fine.

But could you please update your documentation to accurately reflect nyc and c8's install time, as I have told you out of band a few times, nyc and c8's install size has reduced significantly with recent refactoring work we have been doing; as an example, c8 is 2MB not 6MB.

[bcoe]

this isn't worth it, I'm sorry for engaging; philosophically I think it's better to discuss how projects build on each other, or inspire each other, rather than criticizing their shortcomings (this README, and the way you announced your project on Twitter, triggered a pet peeve of mine).

[jaydenseric]

First off, I want you to know that everything I do is done in good faith, for the betterment of the community. I admire some of the work you have done to push the industry in a positive direction.

Update your README to accurately reflect install sizes of nyc and c8

Firstly, the compared nyc and c8 install sizes in the readme at the time every single version was published was 100% accurate when compared against what a user experiences when they run npm install nyc or npm install c8.

Because install sizes change as versions are released, I have linked to the install sizes of the current versions at the time my version is published. If you publish a new version of nyc for example, a user will transparently see the latest size displayed next to the old size when they click the link.

At this very moment, the nyc install size in the readme is perfectly accurate, v15 is in fact 9.01 MB:

https://packagephobia.now.sh/result?p=nyc@15.0.0

The install size for the c8 has indeed changed since I last made commits to this repo:

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

It's still several times the size of this package though, and I will get around to updating the figure as soon as I finish up publishing half finished work on other OSS projects. I've been working on OSS all though Christmas, including Christmas day, I'm doing the best I can man!

given that you rely on dependencies that I wrote

1 dependency, @bcoe/v8-coverage, and you didn't really write it, it's a fork of @c88/v8-coverage. It’s not immediately apparent to people it’s a fork, because for some reason you didn’t use the regular GitHub fork feature. Ideally this dependency will be removed at some point anyway; it’s 271 KB.

Using one of your packages doesn't indebt us to never make fair comparisons to any of your other ones.

I find it a little frustrating that you go out of your way to criticize the install size of nyc and c8 in your documentation

Working several weeks (spending over AUD $1100 of my savings) to write free software for the community, which objectively solves a problem (e.g. megabytes of dev dependencies), has earned me the right to advertise how this software improves upon the status quo.

It is acceptable, and good practice in this industry to benchmark and compare solutions with real points of data. I didn’t “criticize” with sentences, just 1 point of data. The reality is that people won't refactor their projects to adopt a new dev dependency, without first understanding how it improves on their old tooling.

When I became frustrated by how unnecessarily bloated even the most innovative packages are for testing, my first instinct as an npm package optimization expert was to reach out with a friendly tone and lend a hand:

bcoe/c8#173

Instead of acknowledging the issue, and welcoming a potential contributor (who is an OSS fanatic and works for free half the year) you took offense, said there was nothing that could be done, challenged me to make a different library and closed the issue:

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

bcoe/c8#173 (comment)

Frankly I found this response disheartening.

It might not feel like it to you, but you are the establishment; you even work at Google. You seem intent on defending the status quo against independent innovators that are making great sacrifices for little reward. My only reward is the satisfaction of engineering beautiful things that spark joy and make the world a little bit easier for people, but you seem intent to rob me of even that.

They say disruption is easier than reform, and after persevering for years, raising issues and PRs this has proven to be true. Replacing tap with my own test-director and coverage-node packages for testing graphql-api-koa reduced the dev node_modules from 132.1 MB to 51.8 MB:

That’s an 80.3 MB reduction!

I've been rolling out use of coverage-node across a bunch of repos, with higher install count packages to come last (keen to iron out any kinks first). The developer experience has never been better for testing lightweight npm packages, and I'm enthusiastic to share this with the wider community. Unfortunately for this to happen toes must be stepped on.

A rising tide lifts all boats, so @bcoe I hope we can work together on some of the coverage-node and c8 shared challenges.

No hard feelings here, I hope you have a merry Christmas.

[bcoe]

@jaydenseric I appreciate your contribution to the community, and I apologize if my original response to your post came across as disheartening; this very much goes against how I want to convey myself.

Your critique of the module size hit a nerve with me:

1. there's a strong element of truth to your critique about module size (I've been considering whether I should build new reporters from the get go).
2. working on c8 has felt like pushing a boulder up a hill; I don't think I was as open to feedback as I should have been, because I've been occasionally feeling a bit frustrated by the project.
3. keep in mind much of my open-source has also been an evening and weekend endeavor; I don't think I had the mental overhead to deal with your original issue appropriately, I should have been less grumpy.

Looking back at your original post, I agree that my original handling of your issue should have been better (your tone was reasonable, friendly even).

1 dependency, @bcoe/v8-coverage, and you didn't really write it, it's a fork of @c88/v8-coverage. It’s not immediately apparent to people it’s a fork,

You're right, I was thinking of v8-to-istanbul not @bcoe/v8-coverage, credit where credit is due, Charles Samborski did incredible work on this module.

---

I don't love it when open-source projects go out of their way to emphasize themselves in relations to other projects, e.g., project x is 50 times faster than y, or 50% smaller than z....

But,

I think your criticism of how I approached handling your feedback on c8 is fair, I wasn't creating enough space for feedback, and I wasn't as encouraging as I should have been.

I hope you will accept my apology.

[jaydenseric]

🙌