Comment by adev_ | Hacker News Reader

Comment by adev_ | Hacker News Reader

Parent Full thread

> Perl (cpan), Python (pip or conda), Ruby (gem), and Rust (cargo) all behave as NPM does

Wrong.

None of them have chosen the "micro-package" way of NPM.

None of them have an average size of "3-10" line of code per package, which NPM has for many MANY packages. Cargo, pip have many packages but "reasonnable size" packages. ( > 100 lines ).

The Micro-package philosophy that NPM chose, meaning every single line of code can have its own package, increase by several factor the number of dependencies required to create anything in JS.

A simple hello world in react already have ~100 dependencies

https://npm.anvaka.com/#/view/2d/react-create-app

Some core utility bundler/packer/etc overpasses 2000 dependencies

https://npm.anvaka.com/#/view/2d/webpack

This is madness.

It is a simple evidence that bigger the dependency tree is, higher the chance of "one element" malicious / corrupted is.

Maybe the NPM developpers / users should reflect on what lead to this situation instead of closing their eyes and sing "everything is fine".

Nobody is closing their eyes and singing "everything is fine." A large number of small packages is a good thing, and a technically strong ecosystem supports it. Having spent the last week in the internals of glibc chasing bugs in code that has no reason to be jammed into the same library that handles initial program loading, I can attest that there are good, justifiable, technical reasons to do things the NPM way, and I'm glad that there are smart, qualified, talented people implementing that.

I know it's hard for you to imagine, but perhaps the JavaScript ecosystem has some good things about it.

> I know it's hard for you to imagine, but perhaps the JavaScript ecosystem has some good things about it.

There is good in very ecosystem. But a simple keyword "node_modules" on twitter should probably convince you that the good of JS is not in its package system.

To be fair, even the NodeJS author agree on that.

Modularity does not mean "split your code at the atomic level".

JavaScript's package manager is a massive plus to the ecosystem.

The language would not be worth using without it.

> None of them have chosen the "micro-package" way of NPM.

This is not something inherent to npm itself, it's what the people using npm choose to publish.

No matter if people like small modules or not, it's not at all related to the topic discussed.

> No matter if people like small modules or not, it's not at all related to the topic discussed.

It is very relevant to the topic discussed.

Just for fun :

https://npm.anvaka.com/#/view/2d/purescript

> 150 dependencies.

Including a package named "one-time", bundled several times in two different versions. To do something highly relevant and technical like "Call a function once".

I have no doubt that it is an Highly complex code that requires indeed two packages..... Irony

Little question: What would have been the probability of purescript getting malicious if its dependency tree would be something reasonnable... Let's say 20 packages instead of the current ~200 ?

Thank you for linking to that dependency grapher.

The crab-grass like dependencies of many/most NPM packages is scary enough, and then they (or you?), I guess because of lazy loading, to improve responsiveness, update it as you watch.. It's like a scene out of an alien monster movie, where the creature keeps growing more limbs.

Reply on news.ycombinator.com