Hacker News Reader

Comment by james-mcelwain | Hacker News Reader

Why is number of packages and not package size the relevant metric here? Especially when all the packages live in the same repository, there's practically no more overhead to review each package qua package, versus just a bunch of directories in a package monolith.

This "144 times longer" number seems pulled completely out of thin air.

View on HN

Twelve packages with twelve dependencies each is 144. I’ve seen >10x this level of blow up on multiple products at multiple companies.

One company missed installing malware behind all the firewalls of most of the fortune 500 by less than a week.

We made a procedural change to the build process of a product that had been shipping for years.

The change hit our CI/CD 5 days before one of the big language package managers started spewing malware at us.

Package maintainer count bloat is a serious real world problem.

Ignoring it is negligent.

I'm not suggesting that we should stop reviewing dependencies. I'm pushing back against the idea that internally structuring a large repo or project via independent modules necessarily explodes the burden to review.

It may be the case that this preference for well modularized code leads to lots of disparate small packages in the ecosystem, but within the scope of a single project, I see no reason why modularization poses any intrinsic risk.

Both are relevant. To their point, each additional maintainer is also a hidden dependency of each package, so the number of packages is relevant.

In the case in question the dependency count as crates is separate from the dependency count as git repos. In this case things that would normally be one big library where split in many different functional crates in the same repo.

Reply on news.ycombinator.com