7 ms·

One of the problems I see are the super popular holdover packages before ES6 was standardized on. The tread mentions the `foreach` package. And remembering back

One of the problems I see are the super popular holdover packages before ES6 was standardized on. The tread mentions the `foreach` package. And remembering back, many previous supply chain attacks were on these small packages like: `iseven`, `isodd`, etc. I don't fully understand why packages like this are so popular. My guess is it has to be a combo of legacy projects pulling those deps in and inexperienced developers not knowing that these features are now part of standard JS. While this would cause controversy, I think that NPM should lock all these dependencies down and not allow any modifications. The modules would basically be passthroughs to native ES6 functionality. I'm not saying NPM should lock down all legacy packages, just the ones that implemented ES6 functionality (isBetween, isEven, isOdd, forEach, etc)

skrebbel 4y ago
Hahahhahh isBetween, why Compared to that, left-pad is rocket science
- _fat_santa 4y ago
  Nevermind on that one. I just checked NPM and thankfully that package does not exist.
- daurnimator 4y ago
  https://github.com/yefremov/isnan https://github.com/yefremov/isnan An entire module for just `return value !== value;`
  - __s 4y ago
    & ofc there's https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isNaN https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    - jefftk 4y ago
      Which wasn't everywhere in 2017, when isnan was created: IE11 didn't (and still doesn't, though it's less relevant) have isNaN() (Not supporting a culture of taking a dependency for this sort of thing, though)
      - jaywalk 4y ago
        Just to be clear, because your comment made no sense to me: what IE11 doesn't support is Number.isNaN(). It definitely does support (and has since IE3) plain isNaN(): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/isnan#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
        jefftk 4y ago
        Regular isNaN is very tricky, and almost never what you want: it first coerces its input to a Number, and then checks if that is NaN: isNaN Number.isNaN ----- ------------ {} true false [true] true false undefined true false "{}" true false
        jaywalk 4y ago
        But none of those things you listed are numbers. The isNaN output is exactly what I want in pretty much every case.
        jefftk 4y ago
        isNaN does not tell you whether something is not a Number either. Applying isNaN to any of these returns false: null, true, false, [], "", "cabbage".
        dr-detroit 4y ago
  - _Algernon_ 4y ago
    I'm gonna create a package for isX() for each x in the set of integers. Please use my packages for all comparisons from now on.
    - Izkata 4y ago
      is-thirteen is six years old: https://www.npmjs.com/package/is-thirteen https://www.npmjs.com/package/is-thirteen
Vinnl 4y ago
Generally, I don't think they're particularly popular, but a package that depends on them is popular. Or in fact, a package that depends on that package (that depends...) is.
mhitza 4y ago
At least at some point I've randomly stumbled over a GitHub account that had published many NPM packages with one-two function source code. They marketed themselves as a big contributor to the NPM ecosystem, which was directly based upon the number of NPM packages published and the number of monthly downloads. Some packages seemed to take off because people just do a npm install instead of replicating a one line function, while others I think were more popular nodejs projects of this user where they tried to force as many of their own dependencies as they could. TL;DR "SEO" spam to market ones own nodejs expertise, would not be out of the question
krembanan 4y ago
ES6 really has nothing to do with isEven and isOdd
- jamal-kumar 4y ago
  truly... those are just modulo operations
aa-jv 4y ago
>I don't fully understand why packages like this are so popular. I consider 'iseven' and 'isodd' to be signs that Javascript is a hellaciously engineered piece of crap that should be avoided at all costs. They're popular because Javascript is garbage.
- haswell 4y ago
  JavaScript supports the modulo operator and the native syntax for this: let isEven = theNumber % 2 == 0; There are reasons to dislike JavaScript, but this isn’t it. The native solution is about as standard as it gets.
  - jbverschoor 4y ago
    You’re not expressing what you mean by %.. I’m all against these packages, but in Ruby we have a good standard library.
    - krembanan 4y ago
      It's... the modulo operator
      - jbverschoor 4y ago
        Yes. But you’re not expressing what you mean. You don’t want the remainder. It’s like doing a for(i=0; i<items.length:i++) { e=items[i] } to iterate over each element instead of something like foreach, or a lambda.
        haswell 4y ago
        Of all the possible examples to choose, I would not have guessed a classic for/each would be at issue. How is that for loop not expressing what it means? for is used to iterate over something. There are legitimate reasons to choose for even when forEach is available. Does this not express what I mean? if (amount > balance) return “insufficient_funds”; Chances are, I’ll put this in a method anyway, and that’s what a language enables me to do - to create meaning that is contextual to my program. Abstraction can help simplify complex problems, and that’s what it is good at. But when literally everything is abstracted away, it becomes harder to reason about what the program is doing without also learning about what the particular abstraction does (e.g. implicitly handling negative numbers, etc). A well implemented standard library can be a joy to use, and some people choose languages for this reason. Some languages very intentionally provide a very lightweight standard library, and that’s just fine. All of this shouldn’t absolve the developer from understanding some of the very basic constructs of the language they choose - a lack of which will lead to bugs and vulnerabilities. If I choose JavaScript (or it’s chosen for me), it behooves me to understand the basics vs. farming this out to some node package that just made my app harder to reason about and vulnerable to supply chain attacks for essentially no value.
leodriesch 4y ago
I don’t get why anyone would introduce a dependency this small to their codebase. It’s a much better choice to just copy the source code and possibly license into your own code to just eliminate the overhead. It’s not like any of these packages depend on being updated for security reasons or anything.
- bin_bash 4y ago
  I think a lot of it is from a single engineer: sindresorhus He’s a prolific open source author that traditionally had a lot of modularization in his packages—though I think he has started to move away from it recently. He talks about it here: https://blog.sindresorhus.com/small-focused-modules-9238d977a92a https://blog.sindresorhus.com/small-focused-modules-9238d977... Most projects will include at least one package by him in the dependency tree.
  - sanitycheck 4y ago
    Funnily enough, I was just digging through my current project's dependencies and he's slipped in via a Rollup plugin which uses his "globby" package, which in turn uses his "slash" package.. Slash is about 5 lines of code, which is roughly 4 more than most people need for what it does. I vastly prefer to use libraries with 0 dependencies but I never quite manage it, so I end up with the same problems as everyone else.
  - nobleach 4y ago
    For years, the bane of my existence was always lodash. Import one tiny utility and it brings along 15 of its closest friends. You can't get away from it. It was built so incredibly modularly, that it has to import a bunch of other things. Now most folks will quickly rush to its defense and tell you that Webpack should be able to tree-shake it well enough. My actual experience is that it was a tremendous waste of my customers' bandwidth. Seeing LoDash as a dependency of anything I use is an immediate NOPE for me. I've yet to see anything it provides that I couldn't just do myself. It's an unpopular opinion for some silly reason. It's like when Guava or Apache Commons was included on every single Java project in the 2010s. "It's just so much easier to use a well-tested library". That line of thinking is what got us here.
sdevonoes 4y ago
> I don't fully understand why packages like this are so popular. It actually works like this: Author X develops `iseven`, `isodd`, etc. No one really downloads such packages. Author X then develops `importantPackage` which does do something useful developers out here download. The thing is `importantPackage` relies on `iseven` and `isodd`. Now `iseven`, `isodd` are downloaded alongside `importantPackage`. Profit. My point is, we should recognize certain NPM authors as toxic, but I guess "freedom of speech/code" stops us from doing so. Example of such an author: https://github.com/jonschlinkert/ https://github.com/jonschlinkert/
- broken8ball 4y ago
  This guy would lose his shit if npm locked down his packages. I’m probably just venting but he’s been nothing but rude to me any time I’ve opened a legitimate issue on any of the larger downstream libraries of his. Not to mention, his Twitter is something else.
deleted 4y ago
[deleted]

skrebbel 4y ago

Hahahhahh isBetween, why Compared to that, left-pad is rocket science

_fat_santa 4y ago
Nevermind on that one. I just checked NPM and thankfully that package does not exist.
daurnimator 4y ago
https://github.com/yefremov/isnan https://github.com/yefremov/isnan An entire module for just `return value !== value;`
- __s 4y ago
  & ofc there's https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isNaN https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - jefftk 4y ago
    Which wasn't everywhere in 2017, when isnan was created: IE11 didn't (and still doesn't, though it's less relevant) have isNaN() (Not supporting a culture of taking a dependency for this sort of thing, though)
    - jaywalk 4y ago
      Just to be clear, because your comment made no sense to me: what IE11 doesn't support is Number.isNaN(). It definitely does support (and has since IE3) plain isNaN(): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/isnan#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
      - jefftk 4y ago
        Regular isNaN is very tricky, and almost never what you want: it first coerces its input to a Number, and then checks if that is NaN: isNaN Number.isNaN ----- ------------ {} true false [true] true false undefined true false "{}" true false
        jaywalk 4y ago
        But none of those things you listed are numbers. The isNaN output is exactly what I want in pretty much every case.
        jefftk 4y ago
        isNaN does not tell you whether something is not a Number either. Applying isNaN to any of these returns false: null, true, false, [], "", "cabbage".
        dr-detroit 4y ago
- _Algernon_ 4y ago
  I'm gonna create a package for isX() for each x in the set of integers. Please use my packages for all comparisons from now on.
  - Izkata 4y ago
    is-thirteen is six years old: https://www.npmjs.com/package/is-thirteen https://www.npmjs.com/package/is-thirteen

Vinnl 4y ago

Generally, I don't think they're particularly popular, but a package that depends on them is popular. Or in fact, a package that depends on that package (that depends...) is.

mhitza 4y ago

At least at some point I've randomly stumbled over a GitHub account that had published many NPM packages with one-two function source code. They marketed themselves as a big contributor to the NPM ecosystem, which was directly based upon the number of NPM packages published and the number of monthly downloads. Some packages seemed to take off because people just do a npm install instead of replicating a one line function, while others I think were more popular nodejs projects of this user where they tried to force as many of their own dependencies as they could. TL;DR "SEO" spam to market ones own nodejs expertise, would not be out of the question

krembanan 4y ago

ES6 really has nothing to do with isEven and isOdd

jamal-kumar 4y ago
truly... those are just modulo operations

aa-jv 4y ago

>I don't fully understand why packages like this are so popular. I consider 'iseven' and 'isodd' to be signs that Javascript is a hellaciously engineered piece of crap that should be avoided at all costs. They're popular because Javascript is garbage.

haswell 4y ago
JavaScript supports the modulo operator and the native syntax for this: let isEven = theNumber % 2 == 0; There are reasons to dislike JavaScript, but this isn’t it. The native solution is about as standard as it gets.
- jbverschoor 4y ago
  You’re not expressing what you mean by %.. I’m all against these packages, but in Ruby we have a good standard library.
  - krembanan 4y ago
    It's... the modulo operator
    - jbverschoor 4y ago
      Yes. But you’re not expressing what you mean. You don’t want the remainder. It’s like doing a for(i=0; i<items.length:i++) { e=items[i] } to iterate over each element instead of something like foreach, or a lambda.
      - haswell 4y ago
        Of all the possible examples to choose, I would not have guessed a classic for/each would be at issue. How is that for loop not expressing what it means? for is used to iterate over something. There are legitimate reasons to choose for even when forEach is available. Does this not express what I mean? if (amount > balance) return “insufficient_funds”; Chances are, I’ll put this in a method anyway, and that’s what a language enables me to do - to create meaning that is contextual to my program. Abstraction can help simplify complex problems, and that’s what it is good at. But when literally everything is abstracted away, it becomes harder to reason about what the program is doing without also learning about what the particular abstraction does (e.g. implicitly handling negative numbers, etc). A well implemented standard library can be a joy to use, and some people choose languages for this reason. Some languages very intentionally provide a very lightweight standard library, and that’s just fine. All of this shouldn’t absolve the developer from understanding some of the very basic constructs of the language they choose - a lack of which will lead to bugs and vulnerabilities. If I choose JavaScript (or it’s chosen for me), it behooves me to understand the basics vs. farming this out to some node package that just made my app harder to reason about and vulnerable to supply chain attacks for essentially no value.

leodriesch 4y ago

I don’t get why anyone would introduce a dependency this small to their codebase. It’s a much better choice to just copy the source code and possibly license into your own code to just eliminate the overhead. It’s not like any of these packages depend on being updated for security reasons or anything.

bin_bash 4y ago
I think a lot of it is from a single engineer: sindresorhus He’s a prolific open source author that traditionally had a lot of modularization in his packages—though I think he has started to move away from it recently. He talks about it here: https://blog.sindresorhus.com/small-focused-modules-9238d977a92a https://blog.sindresorhus.com/small-focused-modules-9238d977... Most projects will include at least one package by him in the dependency tree.
- sanitycheck 4y ago
  Funnily enough, I was just digging through my current project's dependencies and he's slipped in via a Rollup plugin which uses his "globby" package, which in turn uses his "slash" package.. Slash is about 5 lines of code, which is roughly 4 more than most people need for what it does. I vastly prefer to use libraries with 0 dependencies but I never quite manage it, so I end up with the same problems as everyone else.
- nobleach 4y ago
  For years, the bane of my existence was always lodash. Import one tiny utility and it brings along 15 of its closest friends. You can't get away from it. It was built so incredibly modularly, that it has to import a bunch of other things. Now most folks will quickly rush to its defense and tell you that Webpack should be able to tree-shake it well enough. My actual experience is that it was a tremendous waste of my customers' bandwidth. Seeing LoDash as a dependency of anything I use is an immediate NOPE for me. I've yet to see anything it provides that I couldn't just do myself. It's an unpopular opinion for some silly reason. It's like when Guava or Apache Commons was included on every single Java project in the 2010s. "It's just so much easier to use a well-tested library". That line of thinking is what got us here.

sdevonoes 4y ago

> I don't fully understand why packages like this are so popular. It actually works like this: Author X develops `iseven`, `isodd`, etc. No one really downloads such packages. Author X then develops `importantPackage` which does do something useful developers out here download. The thing is `importantPackage` relies on `iseven` and `isodd`. Now `iseven`, `isodd` are downloaded alongside `importantPackage`. Profit. My point is, we should recognize certain NPM authors as toxic, but I guess "freedom of speech/code" stops us from doing so. Example of such an author: https://github.com/jonschlinkert/ https://github.com/jonschlinkert/

broken8ball 4y ago
This guy would lose his shit if npm locked down his packages. I’m probably just venting but he’s been nothing but rude to me any time I’ve opened a legitimate issue on any of the larger downstream libraries of his. Not to mention, his Twitter is something else.

deleted 4y ago

[deleted]