5 ms·

The issue is especially bad, and needs to be especially called out, for npm because of the insane dependency bloat. You can write fully featured and useful pyt

The issue is especially bad, and needs to be especially called out, for npm because of the insane dependency bloat. You can write fully featured and useful python apps with just the standard packages that come with python. In JS you need a handful of third party packages just to tell if a number is odd. A difference in magnitude becomes a difference in kind.

Hamuko 5y ago
>In JS you need a handful of third party packages just to tell if a number is odd. You really don't, but for some reason JS developers have decided that this is the optimal way to check if a number is odd.
- bavell 5y ago
  > You really don't, but for some reason JS interns have decided that this is the optimal way to check if a number is odd. FTFY :)
  - Hamuko 5y ago
    is-odd gets about two million downloads a month. is-number gets 278 million downloads a month. I guess the interns have been very busy.
    - pfraze 5y ago
      Those numbers are a little deceiving. It’s likely that those modules are upstream of a popular module or two. It’s not like they are installed by projects directly.
      - hombre_fatal 5y ago
        It's only directly depended on by 40 or so npm modules, and most of them look like beginner/joke modules like "is-ten-thousand" where they brag about being featured in a "worst npm libraries" article. Quickly in these sorts of conversations, we're really just making fun of beginners for using dumb packages. With the popularity of Node, it makes sense to me that you can have beginners searching npm/google for how to tell if a number is odd, and for whatever reason they find is-odd or whatever. And perhaps the idea of even collecting packages to do simple things is something fun for them. I remember having a weird maximalist attitude when I was a beginner using Rails. I'd install a Ruby gem and I could use it anywhere in my files without even importing it, usually a single line of abstraction. For some reason that appealed to me even though I could have done it myself. I think I had this idea that people writing libraries were doing things right, and I was right for tapping into them. I think we should save our denigration for the serious, popular projects that use packages rather than the fact that beginners use them. Like, this sort of package has no business being a transitive dep of Express (it isn't) and popular Express middleware, and mainly because x-deps are security issues.
        pfraze 5y ago
        Very good points, and I think you're right on the numbers here! I went dependent spelunking - almost half of it is because is-even is a dependent (naturally) but then I didn't notice any dependents of is-even to explain it. I guess people do just google it and grab the module. Mea culpa for the unsubstantiated assertion before.
        lucideer 5y ago
        handlebars-helpers is one of the big dependents afaik.
    - bryanrasmussen 5y ago
      is-odd package.json contains "dependencies": { "is-number": "^6.0.0" },
- marcosdumay 5y ago
  If I remember correctly, that library was a joke. That people immediately started exhorting as "the right way to do it" as a joke. That due to Poe's law other people immediately understood as the right way to do it...
- zkldi 5y ago
  This is absolutely not true, and I'm tired of seeing this. is-odd, alongside a bunch of other microdependencies are almost all the work of one person, who made as many micropackages as possible and then PRd them into other more popular libraries. There are not 6 million people directly downloading `is-odd` a day. At all. When this person could make one library to do something (like an ANSI-Colouring package), they would fractalise it into as many dependencies as possible, because that boosts their download count on NPM. I should note that this is just one person who has managed to nestle their way into some larger projects. I apologise for the spam, but this point really needs hammering home: https://github.com/jonschlinkert/ansi-black https://github.com/jonschlinkert/ansi-black https://github.com/jonschlinkert/ansi-reset https://github.com/jonschlinkert/ansi-reset https://github.com/jonschlinkert/ansi-bold https://github.com/jonschlinkert/ansi-bold https://github.com/jonschlinkert/ansi-dim https://github.com/jonschlinkert/ansi-dim https://github.com/jonschlinkert/ansi-italic https://github.com/jonschlinkert/ansi-italic https://github.com/jonschlinkert/ansi-underline https://github.com/jonschlinkert/ansi-underline https://github.com/jonschlinkert/ansi-inverse https://github.com/jonschlinkert/ansi-inverse https://github.com/jonschlinkert/ansi-hidden https://github.com/jonschlinkert/ansi-hidden https://github.com/jonschlinkert/ansi-strikethrough https://github.com/jonschlinkert/ansi-strikethrough https://github.com/jonschlinkert/ansi-black https://github.com/jonschlinkert/ansi-black https://github.com/jonschlinkert/ansi-red https://github.com/jonschlinkert/ansi-red https://github.com/jonschlinkert/ansi-green https://github.com/jonschlinkert/ansi-green https://github.com/jonschlinkert/ansi-yellow https://github.com/jonschlinkert/ansi-yellow https://github.com/jonschlinkert/ansi-blue https://github.com/jonschlinkert/ansi-blue https://github.com/jonschlinkert/ansi-magenta https://github.com/jonschlinkert/ansi-magenta https://github.com/jonschlinkert/ansi-cyan https://github.com/jonschlinkert/ansi-cyan https://github.com/jonschlinkert/ansi-white https://github.com/jonschlinkert/ansi-white https://github.com/jonschlinkert/ansi-gray https://github.com/jonschlinkert/ansi-gray https://github.com/jonschlinkert/ansi-grey https://github.com/jonschlinkert/ansi-grey https://github.com/jonschlinkert/ansi-bgblack https://github.com/jonschlinkert/ansi-bgblack https://github.com/jonschlinkert/ansi-bgred https://github.com/jonschlinkert/ansi-bgred https://github.com/jonschlinkert/ansi-bggreen https://github.com/jonschlinkert/ansi-bggreen https://github.com/jonschlinkert/ansi-bgyellow https://github.com/jonschlinkert/ansi-bgyellow https://github.com/jonschlinkert/ansi-bgblue https://github.com/jonschlinkert/ansi-bgblue https://github.com/jonschlinkert/ansi-bgmagenta https://github.com/jonschlinkert/ansi-bgmagenta https://github.com/jonschlinkert/ansi-bgcyan https://github.com/jonschlinkert/ansi-bgcyan https://github.com/jonschlinkert/ansi-bgwhite https://github.com/jonschlinkert/ansi-bgwhite
- kybernetikos 5y ago
  Can you cite anyone who actually thinks this? People complain about these tiny packages they find on npm the whole time, but usually these packages come from people learning how to create their first npm packages, or creating or following tutorials. They aren't serious packages used by typical developers for production apps. If you go to the isEven github repository you can even see "I created this in 2014, when I was learning how to program." If you hover over his 'organisation' you'll see the text "This is a joke. You'll only see this org if you are attempting to troll me about repositories I created when I was learning to program."
  - dahfizz 5y ago
    is-odd gets between 400k and 500k downloads every week[1]. The package was written as an exercise in learning how to create a small, useless package. But a huge portion of the JS development community choosed to import and use the package anyway. [1] https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd
    - kybernetikos 5y ago
      Have a look at where those downloads are coming from and which packages are actually using it: https://www.npmjs.com/browse/depended/is-even https://www.npmjs.com/browse/depended/is-even They're jokes or satire or learning repositories, like `install-is`: "Installing this package installs a bunch of useless packages" or Stalinsort or module-practice-january. The most serious looking dependents are by the same author.
      - imtringued 5y ago
        You aren't looking hard enough. The joke libraries don't get any downloads. install-is gets 1 weekly download. https://news.ycombinator.com/item?id=30991487 https://news.ycombinator.com/item?id=30991487
        kybernetikos 5y ago
        handlebars-helpers falls under my last sentence. The linked thread is literally with the guy who wrote is-odd.
fbrchps 5y ago
> In JS you need a handful of third party packages just to tell if a number is odd But you absolutely don't. I get that you're taking a worst-case example, but it also stands that if Node developers would actually take some time to write stuff themselves -- the leftpad situation was absolutely stupid, because `.padStart()` exists -- then the situation wouldn't be nearly as bad. At my workplace, if you can write the functionality in (depending on the scale) a day to a week, then you're not allowed to use a 3rd party package for it. You can _look_ at what other people have done, but doing it in-house leads to less work overall in the future.
- eropple 5y ago
  > the leftpad situation was absolutely stupid, because `.padStart()` exists String.prototype.padStart hit Chrome in January 2017 and Firefox in June 2016. `left-pad` was published in March 2014. A lot of these small packages that seem ridiculous now addressed (sometimes poorly!) missing aspects of the library specification for pretty good reasons. The JS specification has improved a lot over time--I just chuck `ESNext` into the library tsconfig.json for every Node project--but there is a lot of historical baggage with which this kind of dismissal doesn't adequately come to grips.
- Zababa 5y ago
  .padStart() was added precisely because of the leftpad situation.
bavell 5y ago
JS has a weak stdlib so it's definitely more common to need to pull in some deps vs python. Of course, nothing is forcing you to install silly packages that are wrappers for one-liners. > In JS you need a handful of third party packages just to tell if a number is odd. I have no doubt some clueless interns have done this but there is no need to self-inflict this kind of unnecessary pain.
- rndgermandude 5y ago
  >Of course, nothing is forcing you to install silly packages that are wrappers for one-liners. That's the thing... I am effectively forced to install a lot of silly packages, because I need some not-so-silly packages, and these in turn pull in all the silly packages as dependencies of their own (a few levels down the chain). I never installed leftpad (or any package like that) myself, and yet, at one point it was present in basically every node project I ever did, because of indirect dependencies. While this kind of dependency bloat could happen in any language ecosystem, in node/npm it is from my experience by far the worst. I think it's because the javascript and node standard libraries were/are so very limited combined with npm making it too easy to publish and consume packages, and being early enough in the game so supply chain attacks weren't yet on most people's mind. I think, aside from node package maintainers being too nonchalant about pulling in basically silly dependencies, it's also a matter of a lot of package maintainers being very laissez-faire when it comes to maintaining the cruft and doing the tedious work of removing dependencies that are no-longer needed. An example of that - because it bugs me every time I see this show up in my logs, package lock or node_modules - is the isarray package. It's another one-liner, Array.isArray is part of JS since a long time (even IE 9 supports it and IE 9 was EOL in 2016) and the isarray package will just use it when present (i.e. virtually everywhere), and the author recommends to just use the built-in Array.isArray, and yet it's still omnipresent with almost 63 million weekly downloads, 858 direct dependents on npm (with countless other indirect dependents, and dependents not published and therefore not tracked on npm). And the number of weekly downloads still goes up week-by-week, month-by-month.
lucideer 5y ago
Node has horrific dependency bloat, but this is a strawman here because the right response is not "let's assume the dependency bloat is inherent/justified and come up with specific security mitigations" but rather "let's ask ourselves: WHY does Node have such terrible dependency bloat?" I've no idea why, but I've some personal theories: Similar to how PHP has historically been associated with bad code, not all of which can realistically be attributed to the spellings of its API identifiers, I think whenever you have a system that solves the ease-of-use/developer-accessibility problem well, you will end up with the standard of contributor to that system being less skilled, since it's easier for less experienced people to start using it. You see this throughout the NPM package ecosystem: packages developed by very inexperienced engineers being relied upon by big popular projects. This is ultimately a "good problem". You strive to make your tools easy to use, and when you succeed, you end up with more people using them badly. You can argue that tools should be both easy to use and also foolproof, but that's utopian. Let's work towards that but not expect it as a baseline.
capableweb 5y ago
> In JS you need a handful of third party packages just to tell if a number is odd Maybe it's hyperbole, but you definitely don't "need" any third-party package to tell if a number is odd (`i % 2` does the trick). That there exists a package for it doesn't mean that the majority of users actually use it. The standard library for JS is pretty small in general, but I don't think hyperbole is the right way of getting your point across, as I agree with you in general.
- dahfizz 5y ago
  is-odd gets between 400k and 500k downloads every week[1]. Maybe you don't need it, but lots of JS developers have decided that they do. is-odd also depends on is-number, and is-even depends on is-odd. I agree that these packages are trivially implemented by a first party instead of imported, but ~half a million JS developers every week choose to import it instead. _That is the problem_. [1] https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd
  - dvlsg 5y ago
    I'm fairly certain those download numbers include CI runs redownloading the not-cached package over and over, likely via a transitive dependency. I don't think it's fair to say approximately half a million unique JS developers are choosing to import it every week.
    - imtringued 5y ago
      That's the damn problem with npm. This library is responsible for 50% of all downloads to is-even which calls is-odd. https://www.npmjs.com/package/handlebars-helpers https://www.npmjs.com/package/handlebars-helpers Who cares? https://github.com/helpers/handlebars-helpers/issues/315 https://github.com/helpers/handlebars-helpers/issues/315
  - lucideer 5y ago
    These numbers aren't too hard to rack up for well-known packages (even the meme ones like this). e.g. is-odd is a transitive dependency of stuff like handlebars-helpers which gets a lot of downloads and will pull in is-odd automatically.
pfraze 5y ago
I think you have to appreciate the history with node to know why there are so many packages. Node’s growth coincided with GitHub’s and node’s community really adopted the “social programming” trope. You could really make a name for yourself with a popular node module. Javascript had more limitations to work around at the time, and then the desire to reuse code in node and the browser created even more need to abstract common tasks. The “modularize everything” philosophy resulted and it became a kind of game to make as many modules as you could think to make; after all, isn’t code sharing the joy of the FOSS revolution? That era has since peaked and declined. Now I see people make way fewer modules because of the difficult of managing them all. There’s much less cred to earn from a node package. People who did gain social capital from modules are now stuck as maintainers, gaining very little additional value — thus more conversation about paying maintainers with monetary capital, along with abandoned or ownership-transferred code. And, of course, we’re now suffering from the security issues. It’s still an incredibly valuable corpus of modules, but it’s post-bubble. It wasn’t just “js programmers are too novice to know better.” It was people having fun, playing the social game, trying silly ideas, and chasing a meme-wisdom of programming (modules = good).

Hamuko 5y ago

>In JS you need a handful of third party packages just to tell if a number is odd. You really don't, but for some reason JS developers have decided that this is the optimal way to check if a number is odd.

bavell 5y ago
> You really don't, but for some reason JS interns have decided that this is the optimal way to check if a number is odd. FTFY :)
- Hamuko 5y ago
  is-odd gets about two million downloads a month. is-number gets 278 million downloads a month. I guess the interns have been very busy.
  - pfraze 5y ago
    Those numbers are a little deceiving. It’s likely that those modules are upstream of a popular module or two. It’s not like they are installed by projects directly.
    - hombre_fatal 5y ago
      It's only directly depended on by 40 or so npm modules, and most of them look like beginner/joke modules like "is-ten-thousand" where they brag about being featured in a "worst npm libraries" article. Quickly in these sorts of conversations, we're really just making fun of beginners for using dumb packages. With the popularity of Node, it makes sense to me that you can have beginners searching npm/google for how to tell if a number is odd, and for whatever reason they find is-odd or whatever. And perhaps the idea of even collecting packages to do simple things is something fun for them. I remember having a weird maximalist attitude when I was a beginner using Rails. I'd install a Ruby gem and I could use it anywhere in my files without even importing it, usually a single line of abstraction. For some reason that appealed to me even though I could have done it myself. I think I had this idea that people writing libraries were doing things right, and I was right for tapping into them. I think we should save our denigration for the serious, popular projects that use packages rather than the fact that beginners use them. Like, this sort of package has no business being a transitive dep of Express (it isn't) and popular Express middleware, and mainly because x-deps are security issues.
      - pfraze 5y ago
        Very good points, and I think you're right on the numbers here! I went dependent spelunking - almost half of it is because is-even is a dependent (naturally) but then I didn't notice any dependents of is-even to explain it. I guess people do just google it and grab the module. Mea culpa for the unsubstantiated assertion before.
        lucideer 5y ago
        handlebars-helpers is one of the big dependents afaik.
  - bryanrasmussen 5y ago
    is-odd package.json contains "dependencies": { "is-number": "^6.0.0" },
marcosdumay 5y ago
If I remember correctly, that library was a joke. That people immediately started exhorting as "the right way to do it" as a joke. That due to Poe's law other people immediately understood as the right way to do it...
zkldi 5y ago
This is absolutely not true, and I'm tired of seeing this. is-odd, alongside a bunch of other microdependencies are almost all the work of one person, who made as many micropackages as possible and then PRd them into other more popular libraries. There are not 6 million people directly downloading `is-odd` a day. At all. When this person could make one library to do something (like an ANSI-Colouring package), they would fractalise it into as many dependencies as possible, because that boosts their download count on NPM. I should note that this is just one person who has managed to nestle their way into some larger projects. I apologise for the spam, but this point really needs hammering home: https://github.com/jonschlinkert/ansi-black https://github.com/jonschlinkert/ansi-black https://github.com/jonschlinkert/ansi-reset https://github.com/jonschlinkert/ansi-reset https://github.com/jonschlinkert/ansi-bold https://github.com/jonschlinkert/ansi-bold https://github.com/jonschlinkert/ansi-dim https://github.com/jonschlinkert/ansi-dim https://github.com/jonschlinkert/ansi-italic https://github.com/jonschlinkert/ansi-italic https://github.com/jonschlinkert/ansi-underline https://github.com/jonschlinkert/ansi-underline https://github.com/jonschlinkert/ansi-inverse https://github.com/jonschlinkert/ansi-inverse https://github.com/jonschlinkert/ansi-hidden https://github.com/jonschlinkert/ansi-hidden https://github.com/jonschlinkert/ansi-strikethrough https://github.com/jonschlinkert/ansi-strikethrough https://github.com/jonschlinkert/ansi-black https://github.com/jonschlinkert/ansi-black https://github.com/jonschlinkert/ansi-red https://github.com/jonschlinkert/ansi-red https://github.com/jonschlinkert/ansi-green https://github.com/jonschlinkert/ansi-green https://github.com/jonschlinkert/ansi-yellow https://github.com/jonschlinkert/ansi-yellow https://github.com/jonschlinkert/ansi-blue https://github.com/jonschlinkert/ansi-blue https://github.com/jonschlinkert/ansi-magenta https://github.com/jonschlinkert/ansi-magenta https://github.com/jonschlinkert/ansi-cyan https://github.com/jonschlinkert/ansi-cyan https://github.com/jonschlinkert/ansi-white https://github.com/jonschlinkert/ansi-white https://github.com/jonschlinkert/ansi-gray https://github.com/jonschlinkert/ansi-gray https://github.com/jonschlinkert/ansi-grey https://github.com/jonschlinkert/ansi-grey https://github.com/jonschlinkert/ansi-bgblack https://github.com/jonschlinkert/ansi-bgblack https://github.com/jonschlinkert/ansi-bgred https://github.com/jonschlinkert/ansi-bgred https://github.com/jonschlinkert/ansi-bggreen https://github.com/jonschlinkert/ansi-bggreen https://github.com/jonschlinkert/ansi-bgyellow https://github.com/jonschlinkert/ansi-bgyellow https://github.com/jonschlinkert/ansi-bgblue https://github.com/jonschlinkert/ansi-bgblue https://github.com/jonschlinkert/ansi-bgmagenta https://github.com/jonschlinkert/ansi-bgmagenta https://github.com/jonschlinkert/ansi-bgcyan https://github.com/jonschlinkert/ansi-bgcyan https://github.com/jonschlinkert/ansi-bgwhite https://github.com/jonschlinkert/ansi-bgwhite
kybernetikos 5y ago
Can you cite anyone who actually thinks this? People complain about these tiny packages they find on npm the whole time, but usually these packages come from people learning how to create their first npm packages, or creating or following tutorials. They aren't serious packages used by typical developers for production apps. If you go to the isEven github repository you can even see "I created this in 2014, when I was learning how to program." If you hover over his 'organisation' you'll see the text "This is a joke. You'll only see this org if you are attempting to troll me about repositories I created when I was learning to program."
- dahfizz 5y ago
  is-odd gets between 400k and 500k downloads every week[1]. The package was written as an exercise in learning how to create a small, useless package. But a huge portion of the JS development community choosed to import and use the package anyway. [1] https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd
  - kybernetikos 5y ago
    Have a look at where those downloads are coming from and which packages are actually using it: https://www.npmjs.com/browse/depended/is-even https://www.npmjs.com/browse/depended/is-even They're jokes or satire or learning repositories, like `install-is`: "Installing this package installs a bunch of useless packages" or Stalinsort or module-practice-january. The most serious looking dependents are by the same author.
    - imtringued 5y ago
      You aren't looking hard enough. The joke libraries don't get any downloads. install-is gets 1 weekly download. https://news.ycombinator.com/item?id=30991487 https://news.ycombinator.com/item?id=30991487
      - kybernetikos 5y ago
        handlebars-helpers falls under my last sentence. The linked thread is literally with the guy who wrote is-odd.

fbrchps 5y ago

> In JS you need a handful of third party packages just to tell if a number is odd But you absolutely don't. I get that you're taking a worst-case example, but it also stands that if Node developers would actually take some time to write stuff themselves -- the leftpad situation was absolutely stupid, because `.padStart()` exists -- then the situation wouldn't be nearly as bad. At my workplace, if you can write the functionality in (depending on the scale) a day to a week, then you're not allowed to use a 3rd party package for it. You can _look_ at what other people have done, but doing it in-house leads to less work overall in the future.

eropple 5y ago
> the leftpad situation was absolutely stupid, because `.padStart()` exists String.prototype.padStart hit Chrome in January 2017 and Firefox in June 2016. `left-pad` was published in March 2014. A lot of these small packages that seem ridiculous now addressed (sometimes poorly!) missing aspects of the library specification for pretty good reasons. The JS specification has improved a lot over time--I just chuck `ESNext` into the library tsconfig.json for every Node project--but there is a lot of historical baggage with which this kind of dismissal doesn't adequately come to grips.
Zababa 5y ago
.padStart() was added precisely because of the leftpad situation.

bavell 5y ago

JS has a weak stdlib so it's definitely more common to need to pull in some deps vs python. Of course, nothing is forcing you to install silly packages that are wrappers for one-liners. > In JS you need a handful of third party packages just to tell if a number is odd. I have no doubt some clueless interns have done this but there is no need to self-inflict this kind of unnecessary pain.

rndgermandude 5y ago
>Of course, nothing is forcing you to install silly packages that are wrappers for one-liners. That's the thing... I am effectively forced to install a lot of silly packages, because I need some not-so-silly packages, and these in turn pull in all the silly packages as dependencies of their own (a few levels down the chain). I never installed leftpad (or any package like that) myself, and yet, at one point it was present in basically every node project I ever did, because of indirect dependencies. While this kind of dependency bloat could happen in any language ecosystem, in node/npm it is from my experience by far the worst. I think it's because the javascript and node standard libraries were/are so very limited combined with npm making it too easy to publish and consume packages, and being early enough in the game so supply chain attacks weren't yet on most people's mind. I think, aside from node package maintainers being too nonchalant about pulling in basically silly dependencies, it's also a matter of a lot of package maintainers being very laissez-faire when it comes to maintaining the cruft and doing the tedious work of removing dependencies that are no-longer needed. An example of that - because it bugs me every time I see this show up in my logs, package lock or node_modules - is the isarray package. It's another one-liner, Array.isArray is part of JS since a long time (even IE 9 supports it and IE 9 was EOL in 2016) and the isarray package will just use it when present (i.e. virtually everywhere), and the author recommends to just use the built-in Array.isArray, and yet it's still omnipresent with almost 63 million weekly downloads, 858 direct dependents on npm (with countless other indirect dependents, and dependents not published and therefore not tracked on npm). And the number of weekly downloads still goes up week-by-week, month-by-month.

lucideer 5y ago

Node has horrific dependency bloat, but this is a strawman here because the right response is not "let's assume the dependency bloat is inherent/justified and come up with specific security mitigations" but rather "let's ask ourselves: WHY does Node have such terrible dependency bloat?" I've no idea why, but I've some personal theories: Similar to how PHP has historically been associated with bad code, not all of which can realistically be attributed to the spellings of its API identifiers, I think whenever you have a system that solves the ease-of-use/developer-accessibility problem well, you will end up with the standard of contributor to that system being less skilled, since it's easier for less experienced people to start using it. You see this throughout the NPM package ecosystem: packages developed by very inexperienced engineers being relied upon by big popular projects. This is ultimately a "good problem". You strive to make your tools easy to use, and when you succeed, you end up with more people using them badly. You can argue that tools should be both easy to use and also foolproof, but that's utopian. Let's work towards that but not expect it as a baseline.

capableweb 5y ago

> In JS you need a handful of third party packages just to tell if a number is odd Maybe it's hyperbole, but you definitely don't "need" any third-party package to tell if a number is odd (`i % 2` does the trick). That there exists a package for it doesn't mean that the majority of users actually use it. The standard library for JS is pretty small in general, but I don't think hyperbole is the right way of getting your point across, as I agree with you in general.

dahfizz 5y ago
is-odd gets between 400k and 500k downloads every week[1]. Maybe you don't need it, but lots of JS developers have decided that they do. is-odd also depends on is-number, and is-even depends on is-odd. I agree that these packages are trivially implemented by a first party instead of imported, but ~half a million JS developers every week choose to import it instead. _That is the problem_. [1] https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd
- dvlsg 5y ago
  I'm fairly certain those download numbers include CI runs redownloading the not-cached package over and over, likely via a transitive dependency. I don't think it's fair to say approximately half a million unique JS developers are choosing to import it every week.
  - imtringued 5y ago
    That's the damn problem with npm. This library is responsible for 50% of all downloads to is-even which calls is-odd. https://www.npmjs.com/package/handlebars-helpers https://www.npmjs.com/package/handlebars-helpers Who cares? https://github.com/helpers/handlebars-helpers/issues/315 https://github.com/helpers/handlebars-helpers/issues/315
- lucideer 5y ago
  These numbers aren't too hard to rack up for well-known packages (even the meme ones like this). e.g. is-odd is a transitive dependency of stuff like handlebars-helpers which gets a lot of downloads and will pull in is-odd automatically.

pfraze 5y ago

I think you have to appreciate the history with node to know why there are so many packages. Node’s growth coincided with GitHub’s and node’s community really adopted the “social programming” trope. You could really make a name for yourself with a popular node module. Javascript had more limitations to work around at the time, and then the desire to reuse code in node and the browser created even more need to abstract common tasks. The “modularize everything” philosophy resulted and it became a kind of game to make as many modules as you could think to make; after all, isn’t code sharing the joy of the FOSS revolution? That era has since peaked and declined. Now I see people make way fewer modules because of the difficult of managing them all. There’s much less cred to earn from a node package. People who did gain social capital from modules are now stuck as maintainers, gaining very little additional value — thus more conversation about paying maintainers with monetary capital, along with abandoned or ownership-transferred code. And, of course, we’re now suffering from the security issues. It’s still an incredibly valuable corpus of modules, but it’s post-bubble. It wasn’t just “js programmers are too novice to know better.” It was people having fun, playing the social game, trying silly ideas, and chasing a meme-wisdom of programming (modules = good).