documentation about "cost"

[jonschlinkert]

edit: and fwiw, I'm sorry if I'm getting hung up on a language nuance. I know that "cost" technically implies size here. But given the debates about this topic atm, I think that could just be clarified in a brief sentence up front, to avoid misunderstandings. Specifically because by having a tool to identify "bloat", you're making some kind of statement about the impact of having lots of modules. It would be great to see why that "bloat" actually matters. hope that makes sense

---

This just shows the "size" of modules, which these days is obviously negligible and completely transparent to devs. Do you have an information on how size of modules, or the number of files negatively correlates to "cost"?

For instance, anything that describes how these things cause pain for developers, or makes it harder to program or maintain modules would be great. It would also be great to see a comparison of the cost of using highly unit testable and maintainable modules compares to the cost of under-tested monolithic modules that needless re-create the same code that is already well-tested elsewhere. Also, given project A, which has 10 "microlibs", each with a single responsibility (which has the disadvantage of them being in separate node_modules folder), versus project B, which has the same code as project A, maybe even in separate files, but in one node_modules folder), what is the average level of code coverage in "project B" versus "project A"? What is the average number of total outstanding bugs per SLOC in project B versus project A?

Other more specific questions:

• what is the impact to a library when a monolithic library they depend on stops being maintained?
• what is the impact to that library when a microlibs with a single purpose stops being maintained?
• what is the impact of having extra readme's or license files in node_modules?

I'd love to see some actual facts and data in the readme about this!

[siddharthkp]

edit: and fwiw, I'm sorry if I'm getting hung up on a language nuance. I know that "cost" technically implies size here. But given the debates about this topic atm, I think that could just be clarified in a brief sentence up front, to avoid misunderstandings

Totally understandable. To be honest, I realized this too late, the name is misleading - it should be cost-of-npm-packages. or size-of-packages

TL;DR: This is about install speeds and size.

I added the motivation of creating this tool to the README
I have also changed the tagline to be more accurate.

Here are some installation metrics.
These are on travis-ci, the experience on developer machines would be slower than this.

package	children	size	time taken
ava	328	23.49M	20.070s
mocha	22	1.52M	2.238s
browserify	96	16.41M	10.649
webpack	48	7.13M	7.097s
yargs	20	0.66M	6.501s
yargs-parser	1	0.08M	4.989s

[siddharthkp]

@jonschlinkert I know that doesn't answer the questions you have asked, but this package doesn't aim to answer those questions.

And honestly, I don't think I'm the right to answer those questions 😄

[jonschlinkert]

I know that doesn't answer the questions you have asked, but this package doesn't aim to answer those questions.

No I think the additions are great! I think that makes all the difference. Thanks!