←back to thread

1369 points universesquid | 5 comments | | HN request time: 0s | source
Show context
stathibus ◴[] No.45169926[source]
As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?
replies(11): >>45169990 #>>45169999 #>>45170008 #>>45170014 #>>45170015 #>>45170016 #>>45170038 #>>45170063 #>>45170879 #>>45170926 #>>45170953 #
1. rglover ◴[] No.45169990[source]
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).
replies(1): >>45170047 #
2. grishka ◴[] No.45170047[source]
Then the question becomes, why do developers of larger libraries import someone else's module for every little trivial thing?
replies(2): >>45170186 #>>45173011 #
3. rglover ◴[] No.45170186[source]
Because they don't have the slightest clue what they're doing.
replies(1): >>45170847 #
4. jbreckmckye ◴[] No.45170847{3}[source]
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

5. SAI_Peregrinus ◴[] No.45173011[source]
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.