You typically don't. But a lot of packages that you do install depend on smaller stuff like this under the hood (not necessarily good and obviously better handled with bespoke code in the package, but is is what it is).

▲

grishka 4 days ago | parent [-]

Then the question becomes, why do developers of larger libraries import someone else's module for every little trivial thing?

▲

SAI_Peregrinus 4 days ago | parent | next [-]

Sometimes it's not someone else's module, it's their own. They break up the big library into reusable components, and publish them all separately. Essentially taking DRY to an extreme: don't have private functions, make all your implementation details part of the public API & reuse them across projects.

▲

rglover 4 days ago | parent | prev [-]

Because they don't have the slightest clue what they're doing.

	▲	jbreckmckye 4 days ago \| parent [-]
		It's not that either. There are a handful of important packages that are controlled by people who have consulting / commercial interests in OSS activity. These people have an incentive to inflate download numbers. There could be a collective push to move off these deps, but it takes effort and nobody has a strong incentive to be the first