is-odd

There's also a 'is-even' package, which depends on 'is-odd', which in turn, depends on 'is-number'. 'is-odd' is a little bit more involved than 'is-even'. What it does, is: > Returns true if the given number is odd, and is an integer that does not exceed the JavaScript MAXIMUM_SAFE_INTEGER.[0] The full implementation of 'is-number' is as follows: 'use strict'; module.exports = function(num) { if (typeof num === 'number') { return num - num === 0; } if (typeof num === 'string' && num.trim() !== '') { return Number.isFinite ? Number.isFinite(+num) : isFinite(+num); } return false; }; Ridiculous as it may be, my guess is that provides a unified way of number checking while avoiding the pitfalls or crazy consequences which could arise from divide-by-zero[1], which I guess might preve

Here you go: /*! * is-odd <https://github.com/jonschlinkert/is-odd> * * Copyright (c) 2015-2017, Jon Schlinkert. * Released under the MIT License. */ 'use strict'; const isNumber = require('is-number'); module.exports = function isOdd(value) { const n = Math.abs(value); if (!isNumber(n)) { throw new TypeError('expected a number'); } if (!Number.isInteger(n)) { throw new Error('expected an integer'); } if (!Number.isSafeInteger(n)) { throw new Error('value exceeds maximum safe integer'); } return (n % 2) === 1; }; It does some checking the `value` is an integer in the safe range, which doesn't even seem right to me. Why shouldn't you be able to call this on integers outside the save range?

Although it's unclear, every time someone provides a one liner there are staunch not satire arguments about "covering edge cases you didn't think of" and I disagree. Look at the actual code: https://github.com/i-voted-for-trump/is-odd/ There's a "tested edge case" where you can check isOdd('1') and it will work - to me the code is already wrong, isOdd(STRING) should throw. The correct solution is to use Typescript and assert the input is a number. The Number.isSafeInteger check is an interesting one. Yes, it's not "safe" to work with a number outside this but no doubt something in the function would be broken before an is-odd check if it was relied upon. Often the edge case someone else catered to is something counter to my expectation. I would rather write two lines of code myself and be aware of the behaviour.

I think that this approach would cut down the amount of JS dependencies significantly. Things like is-even and is-odd come to mind. You don't want another leftpad or colors.js to happen to you and minimising dependencies is the most effective strategy to accomplish that. So many leaf dependencies I've looked into are no more than a Stackoverflow answer in a JS file accompanied by six or seven metadata files (package.json + typescript files + linter config + readme + git config + ...). This file: https://github.com/i-voted-for-trump/is-odd/blob/master/inde... is downloaded over 400000 times per week (https://www.npmjs.com/package/is-odd) and while I don't have anythimg against the author for publishing a helpers function, I don't see why I would expose my project to risking a supply chain attack for something so minor. Here's another, wit

You can thank Jon Schlinkert for that: https://github.com/jonschlinkert?tab=repositories He abandoned the projects, but: * https://github.com/jonschlinkert/is-odd * https://github.com/jonschlinkert/is-even Of course that doesn't stop them from getting ~500k downloads/week.

Looking at the commit history, they've mostly added checks for edge cases: https://github.com/jonschlinkert/is-odd/commits/master Which is, to be fair, exactly the reason you'd use a library like this.

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. 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.

It's funny, because in the case we're talking about, there appears to be edge case behavior if the number is a "safeInteger." While I agree in principle I would never import something as granular as "is-odd," just researching this specific package revealed an edge case someone ran into and solved, and you don't have to worry about as a dev if you take it off the shelf. https://github.com/jonschlinkert/is-odd/blob/master/index.js...

No he did not. https://github.com/jonschlinkert/is-odd/commit/dcc7eeff5be8f...

https://github.com/jonschlinkert/is-odd/blob/master/index.js Edit: the original code, even before the float handling, was was a perf optimisation: !!(~~i & 1); Nobody wants to see that in code unless it has a name. Maybe isOdd(). Maybe we should put it on GitHub to save others time. Sure beats copy-pasting from StackOverflow. Original: Did you think of handling floats in your home built isOdd implementation? Thankfully Jon (EDIT: or one of his contributors - doesn't change the point) did. And they added tests. The (flagged) article makes the staggering assumption that "we can't code" because we're not constantly reinventing the wheel. It talks about DRY being taken too far and talks about the functions being replaced as "one liners", when following a couple of links would show they're not. We can code, we're just coding on actual fea