5 ms·

One can see why this happens when packes like [1] and [2] not only exist, but are frequently used. [1] https://www.npmjs.com/package/is-even https://www.npmjs.

One can see why this happens when packes like [1] and [2] not only exist, but are frequently used. [1] https://www.npmjs.com/package/is-even https://www.npmjs.com/package/is-even [2] https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd EDIT: my favourite part, is-even depends on is-odd. https://github.com/jonschlinkert/is-even/blob/master/index.js https://github.com/jonschlinkert/is-even/blob/master/index.j...

benjaminsuch 6y ago
I opened the index.js files of both repos and their copyright comment made me chuckle.
nicoburns 6y ago
I feel like somebody ought to start a project which systematically goes through the ecosystem removing these dependencies. For more complex micro-libraries, perhaps they could be collated into a single, larger high quality library.
- wereHamster 6y ago
  Very often these stupid dependencies are at the leaves of the dependency tree, often in packages which no longer get new releases to NPM. Fixing those packages has zero net effect on the whole situation.
- jart 6y ago
  https://opensource.googleblog.com/2017/03/operation-rosehub.html https://opensource.googleblog.com/2017/03/operation-rosehub....
magicalist 6y ago
> but are frequently used. From the short dependents lists, it looks like neither is frequently used directly. Edits to one or two dependent projects would likely be enough to largely eliminate them from the ecosystem.
caseymarquis 6y ago
I immediately thought: "But no one would actually add that dependency!" Only to see 120k weekly downloads of is-even. I... don't understand...
- enriquto 6y ago
  > I... don't understand... You are not supposed to reinvent the wheel. Somebody has already gone through the trouble of implementing the is-even algorithm, and it would be a waste of time to re-write it for no purpose. You may think that it is a simple algorithm, but I doubt you could implement it better than the people who uploaded these files to npm. Notice that the algorithm has many obscure corner-cases that you are likely to miss on your first implementation. Fortunately, it is already written and packaged; just use it.
  - robert-boehnke 6y ago
    Note that this implementation of `isEven` throws on input that isn't a number or numbers that are not integers, NaN or larger than 2^53-1. I think it's fair to argue an implementation could just as well return false for 1.4, NaN or '2'. There is a cost to learning these minutiae of your dependencies, especially if there is no compiler support to assist you.
    - _0ffh 6y ago
      I've not programmed a lot of JS, so this might be obvious for someone who did, but: Why does he first use Math.abs on the parameter and then type check the result of that? I'd think if you do an argument type check, you'd do it before using it. Just to make it not throw on null? I don't see the sense in that...
      - rodw 6y ago
        I'm not sure this is the reason for that specific implementation but `Math.abs` _will_ do a string-to-number conversion. I.e., `Math.abs("-27")` yields `27`. It might be the case that Math.abs does other *-to-number conversions also, so maybe this method is trying to take advantage of that. (Math.abs is usually implemented as a native function so without digging more deeply it's not obvious to me what the actual implementation does.) UPDATE: Curiously, `Math.abs(null)` yields `0`, so a null argument passed to is-even would yield `true` I guess. Also whatever the logic is for that conversion is it is not the same as the built-in `parseInt` or `parseFloat`. `parseInt("27 meters")` yields `27` but `Math.abs("27 meters")` yields `NaN`. Personally in JavaScript I almost universally make use of home-grown `isInt` and `toInt` methods whose behavior is predicable for me -- eg. my toInt() will reject a string that's not _just_ an integer value (and return `null` rather than `NaN` in all cases because who wants to check `isNaN`?) -- but that's probably not a great practice either. But I've been programming long enough to realize that the principle of least surprise is probably the most important concern here for long-term efficiency. I suppose what is or is not surprising may be subjective though.
onion2k 6y ago
Anyone who needs to test an input is an odd number using vanilla JS will eventually end up rolling something that looks a lot like isOdd() themselves (or they'll just ignore a set of potential problems, which definitely is worse). It's very obvious when you read the code - https://github.com/jonschlinkert/is-odd/blob/master/index.js https://github.com/jonschlinkert/is-odd/blob/master/index.js. Utilities like that are a function of using a weakly typed language. "Just use TypeScript" is an alternative solution, but even in TS you should still check the number is within the bounds of isSafeInteger.
- rozab 6y ago
  But why should isOdd, isEven and isNumber reside in seperate packages? Surely a single math tools package should cover all of this?
  - wongarsu 6y ago
    It's an overreaction to the critizism of bloated libraries like JQuery. Dead code removal with tree shaking is a relatively recent feature in JS toolchains, so instead you have single-function libraries. For example there are also npm packages with each lodash function as its own package [1] 1: https://www.npmjs.com/search?q=keywords:lodash-modularized https://www.npmjs.com/search?q=keywords:lodash-modularized
  - z3t4 6y ago
    Think of it like being able to pull any function from a global scope. eg. var/const foo = require("bar") Its one gigantic standard library.
  - onion2k 6y ago
    Surely a single math tools package should cover all of this? They shouldn't. It's silly. You're right that there should be "math"[1], but while those things aren't part of the main JS ecosystem people write utility libraries and publish them. [1] There is, it's https://mathjs.org/ https://mathjs.org/. More people should use it.
- Carpetsmoker 6y ago
umvi 6y ago
> EDIT: my favourite part, is-even depends on is-odd. Probably because it just does return !is-odd(x); So it can take advantage of all the type checking and other corner case junk in `is-odd`
- Kye 6y ago
  It does seem like JavaScript/NPM has the advantages of composability found in Unix tools. It's no different from zcat | grep or similar. All that's different is the people making these tools have a wider range of experience and knowledge than people hacking on C making Unix tools, and easier distribution.
  - 15rthughes 6y ago
    There’s an argument to be made that micro packages follow the ideas of the Unix philosophy, but to compare is-odd and a derivative that simply negates it’s results to piping two well optimized coreutils together is definitely a stretch. I’d also say that implying JS developers inherently have a wider range of experience and knowledge compared to developers of coreutils is flat out absurd.
    - Kye 6y ago
      >> "I’d also say that implying JS developers inherently have a wider range of experience and knowledge compared to developers of coreutils is flat out absurd." I was way too ambiguous, so I see how you understood it that way. I meant in the downward direction. There are more packages from more people in JS, so you end up with lots of first projects, small experiments, etc. So you have 100% of coreutils being decent to amazing, while it's probably closer to 1% with NPM. Both ways have their advantages, but it's easier to footgun with the highly inclusive NPM approach.
slykar 6y ago
It gets better when you read the repo description. > I created this in 2014, when I was learning how to program. Someone probably just did this for the fun of learning and somehow it got adopted elsewhere.
deleted 6y ago
[deleted]

benjaminsuch 6y ago

I opened the index.js files of both repos and their copyright comment made me chuckle.

nicoburns 6y ago

I feel like somebody ought to start a project which systematically goes through the ecosystem removing these dependencies. For more complex micro-libraries, perhaps they could be collated into a single, larger high quality library.

wereHamster 6y ago
Very often these stupid dependencies are at the leaves of the dependency tree, often in packages which no longer get new releases to NPM. Fixing those packages has zero net effect on the whole situation.
jart 6y ago
https://opensource.googleblog.com/2017/03/operation-rosehub.html https://opensource.googleblog.com/2017/03/operation-rosehub....

magicalist 6y ago

> but are frequently used. From the short dependents lists, it looks like neither is frequently used directly. Edits to one or two dependent projects would likely be enough to largely eliminate them from the ecosystem.

caseymarquis 6y ago

I immediately thought: "But no one would actually add that dependency!" Only to see 120k weekly downloads of is-even. I... don't understand...

enriquto 6y ago
> I... don't understand... You are not supposed to reinvent the wheel. Somebody has already gone through the trouble of implementing the is-even algorithm, and it would be a waste of time to re-write it for no purpose. You may think that it is a simple algorithm, but I doubt you could implement it better than the people who uploaded these files to npm. Notice that the algorithm has many obscure corner-cases that you are likely to miss on your first implementation. Fortunately, it is already written and packaged; just use it.
- robert-boehnke 6y ago
  Note that this implementation of `isEven` throws on input that isn't a number or numbers that are not integers, NaN or larger than 2^53-1. I think it's fair to argue an implementation could just as well return false for 1.4, NaN or '2'. There is a cost to learning these minutiae of your dependencies, especially if there is no compiler support to assist you.
  - _0ffh 6y ago
    I've not programmed a lot of JS, so this might be obvious for someone who did, but: Why does he first use Math.abs on the parameter and then type check the result of that? I'd think if you do an argument type check, you'd do it before using it. Just to make it not throw on null? I don't see the sense in that...
    - rodw 6y ago
      I'm not sure this is the reason for that specific implementation but `Math.abs` _will_ do a string-to-number conversion. I.e., `Math.abs("-27")` yields `27`. It might be the case that Math.abs does other *-to-number conversions also, so maybe this method is trying to take advantage of that. (Math.abs is usually implemented as a native function so without digging more deeply it's not obvious to me what the actual implementation does.) UPDATE: Curiously, `Math.abs(null)` yields `0`, so a null argument passed to is-even would yield `true` I guess. Also whatever the logic is for that conversion is it is not the same as the built-in `parseInt` or `parseFloat`. `parseInt("27 meters")` yields `27` but `Math.abs("27 meters")` yields `NaN`. Personally in JavaScript I almost universally make use of home-grown `isInt` and `toInt` methods whose behavior is predicable for me -- eg. my toInt() will reject a string that's not _just_ an integer value (and return `null` rather than `NaN` in all cases because who wants to check `isNaN`?) -- but that's probably not a great practice either. But I've been programming long enough to realize that the principle of least surprise is probably the most important concern here for long-term efficiency. I suppose what is or is not surprising may be subjective though.

onion2k 6y ago

Anyone who needs to test an input is an odd number using vanilla JS will eventually end up rolling something that looks a lot like isOdd() themselves (or they'll just ignore a set of potential problems, which definitely is worse). It's very obvious when you read the code - https://github.com/jonschlinkert/is-odd/blob/master/index.js https://github.com/jonschlinkert/is-odd/blob/master/index.js. Utilities like that are a function of using a weakly typed language. "Just use TypeScript" is an alternative solution, but even in TS you should still check the number is within the bounds of isSafeInteger.

rozab 6y ago
But why should isOdd, isEven and isNumber reside in seperate packages? Surely a single math tools package should cover all of this?
- wongarsu 6y ago
  It's an overreaction to the critizism of bloated libraries like JQuery. Dead code removal with tree shaking is a relatively recent feature in JS toolchains, so instead you have single-function libraries. For example there are also npm packages with each lodash function as its own package [1] 1: https://www.npmjs.com/search?q=keywords:lodash-modularized https://www.npmjs.com/search?q=keywords:lodash-modularized
- z3t4 6y ago
  Think of it like being able to pull any function from a global scope. eg. var/const foo = require("bar") Its one gigantic standard library.
- onion2k 6y ago
  Surely a single math tools package should cover all of this? They shouldn't. It's silly. You're right that there should be "math"[1], but while those things aren't part of the main JS ecosystem people write utility libraries and publish them. [1] There is, it's https://mathjs.org/ https://mathjs.org/. More people should use it.
Carpetsmoker 6y ago

umvi 6y ago

> EDIT: my favourite part, is-even depends on is-odd. Probably because it just does return !is-odd(x); So it can take advantage of all the type checking and other corner case junk in `is-odd`

Kye 6y ago
It does seem like JavaScript/NPM has the advantages of composability found in Unix tools. It's no different from zcat | grep or similar. All that's different is the people making these tools have a wider range of experience and knowledge than people hacking on C making Unix tools, and easier distribution.
- 15rthughes 6y ago
  There’s an argument to be made that micro packages follow the ideas of the Unix philosophy, but to compare is-odd and a derivative that simply negates it’s results to piping two well optimized coreutils together is definitely a stretch. I’d also say that implying JS developers inherently have a wider range of experience and knowledge compared to developers of coreutils is flat out absurd.
  - Kye 6y ago
    >> "I’d also say that implying JS developers inherently have a wider range of experience and knowledge compared to developers of coreutils is flat out absurd." I was way too ambiguous, so I see how you understood it that way. I meant in the downward direction. There are more packages from more people in JS, so you end up with lots of first projects, small experiments, etc. So you have 100% of coreutils being decent to amazing, while it's probably closer to 1% with NPM. Both ways have their advantages, but it's easier to footgun with the highly inclusive NPM approach.

slykar 6y ago

It gets better when you read the repo description. > I created this in 2014, when I was learning how to program. Someone probably just did this for the fun of learning and somehow it got adopted elsewhere.

deleted 6y ago

[deleted]