Nobody needs to write satire about the state of Javascript package management when people write (and use!) libraries like these.
Nobody needs to write satire about the state of Javascript package management when people write (and use!) libraries like these.
https://github.com/i-voted-for-trump/is-even/blob/master/pac...
2.7.3 :003 > 1.odd?
=> true
2.7.3 :004 > 2.odd?
=> false
2.7.3 :005 > 1.even?
=> false
2.7.3 :006 > 2.even?
=> true
2.7.3 :007 >EDIT: Confirmed, it was added in 1.8.7 according to Ruby Docs [1] [2]
[1] https://ruby-doc.org/core-1.8.7/Integer.html (present)
[2] https://ruby-doc.org/core-1.8.6/Integer.html (not present)
isEven(0);
//=> true
isEven('1');
//=> false
isEven(2);
//=> true
isEven('3');
//=> falseI don't think such packages should be on NPM either way.
This is what it says there:
> 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.
https://mobile.twitter.com/jonschlinkert
He definitely voted for trump.
There is a bit of a culture clash inside Javascript. Even when you're a veteran contributor, sometimes maintainers resist changing packages, as simple as they are, because there is an implicit assumption that popular packages, or even packages with too many dependencies are "better" or "handled all the edge cases".
Even with careful evaluation of the options and a write-down of issues and a proper comparison, you need ten times as much energy to remove a package than it took to add it.
It's even worse is when "too many packages" is in the DNA of the package you're collaborating.