[1] https://www.npmjs.com/package/is-even
[2] 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.j...
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.
1: https://www.npmjs.com/search?q=keywords:lodash-modularized
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/. More people should use it.
"2.2 % 2 === 1" works just as well, so why is the isInteger check needed? Why is the isSafeInteger check needed? And "a % 2" is already NaN (and thus false), although an explicit error is arguably better than silently eating it.
For more complex micro-libraries, perhaps they could be collated into a single, larger high quality library.
> 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.
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.
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...
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.
I think you're getting some down votes as you missed a closing tag.
A lot of JS devs wouldn't bother check those things, so really a lot of code is improved by this library. It's kind of a shame that so many developers just skip over checking inputs really. That's the real problem.
Because, indeed, no-one should be rewriting obvious code like isArray, leftPad, isEven and so on.
Yes, that might cause some overhead in some situations (when you need isOdd, but not leftPad). But I'm certain that overhead is minimal. In practice, however, we currently see dependency-trees where these "should-be-stdlib" modules like "leftPad" or "isArray" are repeated numerous times in one project.
Any stdlib could even be optimized by browsers and engines, turning that "overhead" into a net benefit.
isOdd('') => false
isOdd(null) => false
isOdd(2n) => TypeError: Cannot convert a BigInt value to a number
That's 120k instances of people or scripts doing `npm install is-even` or the equivalent.
For comparison:
* Lodash - a general purpose set of library/utility functions by the way - has ~26M weekly downloads.
* request - an HTTP client library - has ~19M weekly downloads
I wouldn't add is-even as a direct dependency either, but I think people are underestimating the size and diversity of the JavaScript ecosystem as a whole.
Probably because it just does
return !is-odd(x);
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.
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.