Hacker News new | ask | show | jobs
by fmx 903 days ago
When I first heard of the is-odd and is-even NPM packages I was sure they were a joke, yet there we are: 200K weekly downloads! Publishing the packages may have been the effort of one spammer, but many developers obviously chose to use them - that's the part that boggles my mind.
4 comments

Well, look at one of the dependents: https://www.npmjs.com/package/handlebars-helpers - certainly a more useful npm package, but by the same author. Seldom do people actually type `npm install is-even` - there's just a jungle of transitive dependencies that can be traced back to one of jonschlinkert's many packages, which then circles back to something inane as `is-even` or `ansi-red`.

I once ran a simple grep in some of my node projects - most of them had a jonschlinkert package in node_modules, certainly not through any (direct) choice of my own.

Check out this very useful utility: https://github.com/mitsuhiko/is-jonschlinkert :)
Possibly related: https://github.com/SukkaW/nolyfill vs. ljharb and nodejs 4
I recently came across this issue (https://github.com/import-js/eslint-plugin-import/issues/213... and https://github.com/import-js/eslint-plugin-import/issues/181...) and man that person has really found him self a hill.

What is a bit worrying though is that he is an active member and contributor to TC-39. Meaning that this kind of community hostility is very much alive among the people who rule JavaScript.

View their obstinance: https://github.com/nvm-sh/nvm/issues/794

8 years later and despite much support for the `.node-version` file.

Someone else started using the .node-version file years ago, and because all open source packages won't form a committee to standardize this file, nvm will not support it.

They have a lot of hills. JS Private Properties was another.

Very often when I’m digging around GitHub Issues because of some bug or quirk or insanity in the JS ecosystem (which is often) I see someone spout the worst possible take - often being kind of a jerk about it - and when I look to see who’s responsible, very very often, ljharb’s name pops up. Often.

Dogpiling on someone deep in an HN comments tree isn’t exactly the classiest thing but…never having interacted with him myself, I’ve been harbouring this low-grade antipathy towards him - nothing unhealthy, just a groan whenever I see his name on GH - for years now, and it’s cathartic and almost gratifying, given his prominence in the community, to feel seen like this. Thank you.

To be fair, the ESM switch has been botched beyond compare.

It’s like they didn’t want to become Python 2/3, and then did the absolute worst possible alternative.

It is beyond frustrating that it’s up to individual package authors whether or not their package supports ESM or CommonJS.

And yeah, it’s a pita when one of your downstream dependencies decides to go ESM only, and breaks your entire friggin chain of stuff that depends on it being CommonJS.

I agree. Mistakes were made and migration has been unnecessarily hard. This particular issue doesn’t even affect me. I simply turned off `no-unresolved`. TypeScript handles a lot better anyway (even with jsdoc type annotations).

But what is the issue here is the stubbornness of the maintainer and his unwillingness to accommodate a very sizable portion of his user base. The industry is moving on, and as a TC-39 member he should be aware of where the community is moving as well as show some empathy with his users.

I love the release notes:

> It exists.

Would it be considered bad practice or in poor taste to make pull requests in projects with the sole objective of implementing is-even natively?

Thinking of being the change I want to see in the world.

It’s probably contextual but I’d say it’s in poor taste to use them in the first place. Removing them is a net benefit imo.
I see, thanks. I guess that answers one question, but raises another: why have his packages depend on more of his packages? If his goal was to be included in as many node_modules directories as possible, and handlebars-helpers was already included what's the point of pulling in is-odd/is-even, too?
Might be this from his GitHub bio “Several years ago, just before my 40th birthday, I switched careers from sales, marketing and consulting to learn how to program” Good way to get more eyeballs…
Ah yes, that actually explains a lot! Thanks.
Makes is-odd/is-even popular; many downloads; raises their (and his) profile.
Here we are all talking about him now!
He could sell rights to the repos and disavow any knowledge of its maintenance while maintaining the link in his own repos. When those sold rights are used to commit some crime he has plausible deniability as anyone else but got a payday. If you try spinning off the subpackage just prior to a sale then it shows some sort of intent.
Is there any evidence that he has ever done anything like this, or that he plans to? Or is this just pure speculation?
I didn't declare he's done this only that it is a vulnerability of depending on those packages.
I did learn one new thing from browsing the is-odd source code: Number.isSafeInteger(n) checks that n falls within the [Number.MIN_SAFE_INTEGER, Number.MAX_SAFE_INTEGER] interval.

  ...
  if (!Number.isSafeInteger(n)) {
    throw new Error('value exceeds maximum safe integer');
  }
  ...
Shouldn't this simply return true instead of throwing?
Often the is-even package will be imported by another (less ridiculous) package of the same author.
the bigger joke is that programming language have no built in
Huh? Did you miss the modulo operator?
It is not just modulo, it also test for whether the input is a number or integer. It also has one dependency, is-number. And isOdd(“3”) returns true.

Basically it helps dealing with all the typing problems of Javascript, and also fitting into functional programming paradigms.

If you need to know if a number is even or odd then you should convert it to an int natively anyway.
Given the lack of integers and my hesitancy to trust modulo for non-integer variables, I don't know if I would trust it. You would need to add some safety checks, but either you create an is_even/is_odd function that has safety checks, or you have to rely on developers adding in the checks anytime the number might have been in close proximity to a floating point number.

Something as simple as this can end up being neither even or odd.

    (0.1 + 0.2) * 10
It wouldn't have 200k downloads a week unless there was a large number of programmers who didn't know how to do it.

I mean we're talking FizzBuzz secret sauce here. This must be total black magic for a catastrophic percentage of programmers

I have not read the source but I had always assumed that this was the lovingly crafted effort of someone who is intimately familiar with the js standard making sure that some hypothetical expression like ![1] is neither odd nor even. Surely the idea that modulo is beyond developers is too horrifying to contemplate.
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?
(10e15 + 1) % 2 === 0
All non-safe integers are even, yes?
Sad but true. For JavaScript these kind of functions can actually be useful because of all the quirks. If that was the GPs hint then I can understand.
A more catastrophic number of programmers a) dont know how dependencies work and b) think everyone else are idiots.
Perhaps, I solidly understand how dependencies work and in this case my observation is defensible

Someone made the decision to use that and someone thought using stuff made by a person's who makes those kinds of decisions was a good idea and so on.

You can git blame dependencies all the way down and research the parties involved. I've done it, built tools for it even.

A stack of people who make bad decisions doesn't make good software.

More likely the author made another, more useful, package that uses it.