Hacker News Reader

Comment by lvncelot | Hacker News Reader

It's always worth mentioning that those packages stem from the effort of one dedicated npm spammer[1] to weasel his way into as many node_modules directories as possible. There's also packages for ansi-colors (no, not one package for all colors, one package for each color) and god knows what else. These then get jammed into any cli tool or other half-way sensible looking package, all referencing each other obviously - and any "real" project is just a single innocuous dependency away from having dozens of jonschlinkert packages.

[1] https://www.npmjs.com/~jonschlinkert

View on HN

> Several years ago, just before my 40th birthday, I switched careers from sales, marketing and consulting to learn how to program, with the goal of making the world a better place through code [1]

It checks out, sales/consulting folks are pretty infamous for their tendency to abuse metrics. The metric here is npm downloads and Github stars.

The strategy does mean that he's _technically_ not inaccurate in claiming this on his LinkedIn -

> NASA, Microsoft, Google, AMEX, Target, IBM, Apple, Facebook, Airbus, Mercedes, Salesforce, and hundreds of thousands of other organizations depend on code I wrote to power their developer tools and consumer applications.

I encountered this type a lot in college consulting groups, it's a little funny seeing one make their way to the OSS community.

[1] https://github.com/jonschlinkert

Yeah but this might make him the Patient Zero for modern tech influencing and blogspam.

Anyone know if this has spread to crates.io yet? I see plenty of name squatting, but I haven't run into real crates trying to insert themselves into everything. Namespaces are sorely needed, including some semi-official ones. candi::rand would be reasonable for candidates to enter std. Watching the battles over tokio getting into candi would be fun.

> Watching the battles over tokio getting into candi would be fun.

What would be the argument for this? It's my understanding that the lack of a default runtime is considered a strength

> To date, I've created more than 1,000 open source projects

This dude is counting each one as a project hahaha

It's the truth but not the whole truth

It reminds me of graffiti tagging!

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.

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 :)

I love the release notes:

> It exists.

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.

I was doing some snooping around and found this earlier discussion https://news.ycombinator.com/item?id=37602923 from September 2023 (234 points, 110 comments), which I had missed at the time, very related to this current subthread, and includes posts such as these (https://news.ycombinator.com/item?id=37604635).

I think we as a community really need to have a conversation about ljharb and his role in the future of our industry. If he was only a library maintainer, that would be one thing, we could just move on, find workarounds, alternatives, etc. But his involvement in TC-39 makes him one of our rulers in a non-democratic structure. That makes this different.

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

Makes is-odd/is-even popular; many downloads; raises their (and his) profile.

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.

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.

Here we are all talking about him now!

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

the bigger joke is that programming language have no built in

Huh? Did you miss the modulo operator?

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

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.

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.

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.

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?

All non-safe integers are even, yes?

(10e15 + 1) % 2 === 0

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

Often the is-even package will be imported by another (less ridiculous) package of the same author.

My favorite is the existence of both https://github.com/jonschlinkert/ansi-gray and https://github.com/jonschlinkert/ansi-grey that do the exact same thing.

Another classic from jon is the venerable https://www.npmjs.com/package/isobject coming in at 30,000,000 weekly downloads for

`function(val) { return val != null && typeof val === 'object' && Array.isArray(val) === false; }`

But honestly, having seen "TypeError: Cannot read properties of null" enough times, I give it a pass.

https://npm-stat.com/charts.html?author=jonschlinkert paints a pretty crazy picture

Seriously fuck this dude leeching on the open source community.

He's not even a technical guy but has a background i marketing and is directly trolling various Github issues :

https://news.ycombinator.com/item?id=28661094

I've always wondered why node-modules and npm required such an insane amount packages so quickly, and now i know why, people like him that use their 10.000 ridiculous packages to boost their career or do whatever self serving community destroying thing they can think off that day.

There really should be a way to ban people doing this shit.

The author hasn't forced you to import their package. What's there to ban apart from maybe polluting the common namespace?

It's more a statement about the community than him imo. Or maybe about what npm allows to be published. Nobody forced you to use is-odd, yet it's downloaded 200k a week, why? Because js' developer community doesn't know any better

Exactly right. Its clever way of deflecting blame that whole community should share by piling on this particular person.

This really sounds like victim-blaming. The community is vulnerable to somebody publishing asinine modules, which should be addressed. However, this individual is still the perpetrator.

A lot or these downloads may be CI systems running automatic tests.

They clearly are, but this still means a not negligible amount of softwares have those packages in their dependencies.

Maybe someone needs to do a website in the same spirit of https://youmightnotneedjquery.com except youmightnotneedjonschlinkert.

Notice that most dependents of his tools are: 1) his own project, 2) abandoned beginner projects.

As some people mentioned, most of the usage of is-even is by tools made by this person.

But the other part is that, he made quite a few development tools for beginners that scaffold new projects and pull lots of his packages as dependencies (especially the handlebars helper), which heavily inflates the number of "Dependents" in NPM.

The other issue is that, in the past, he managed to include some of his less-useless packages in some semi-popular tools.

I mostly write in languages without package managers so it is possible that my expectations are just wrong, but is there no way of showing your dependency graph when using npm?

Here are some popular ones. Now, in two of these cases, they can be dev-dependencies, but even there, it makes me angry, since all of those deps have to be downloaded to my machine, and can run any random code they want at install time (which is why Node projects should always be run in some kind of sandbox).

https://npm.anvaka.com/#/view/2d/jest

https://npm.anvaka.com/#/view/2d/tailwind

https://npm.anvaka.com/#/view/2d/aws-sdk

> can run any random code they want at install time (which is why Node projects should always be run in some kind of sandbox).

You can install with the --ignore-scripts flag. Or set the option globally in your npm config file.

Isn't the post you linked to about a different person?

> There really should be a way to ban people doing this shit.

???

There is. It's called "doing nothing."

It takes work to add a dependency to your project; they don't spring out of nothing.

That's hilarious. The best part is that he didn't even try to make good packages (not that hard) but just took the lazy route.

Well one reason could be this software proverb: Good programers are lazy programers.

It's weird to me that in every other comment thread on Hacker News, people say "good software should do one thing and do it well". And then the topic moves to NPM, and suddenly everyone loses their mind?

Haha ok do something substantial! It's implied.

A little copying is better than a little dependency.

This is part of the UNIX philosophy, but sometimes this gets taken way too far. There is of course the UNIX command "yes", which literally just prints the character "y" over and over again (to skip interactive prompts).

GNU yes will actually repeat any string—the default is of course "y". So it's very handy for scripting, and not really as single-purpose as you'd think.

Yeah it's definitely useful. Still a bash one liner though:

  function yes { while true; do echo "${1:-y}"; done }

also, it's actually faster than reading /dev/zero if you need some filler data hahahaha

Achieving supply-chain security by controlling every link in the chain. This Jon is very noble.

Packages should specify their entitlements.. network access, file access, executing system calls, being able to monkey patch things, accessing packages outside their own.

Deno has a few of these by default an application has no access to the filesystem, env or network.

You can allow only reading or only writing for files and you can also define what domains are allowed.

Sure it's a huge step forward. But that's on an application level, which honestly I can do with sandbox-exec on macOS (see below).

In Deno, all permissions would still propagate down to the dependencies.

  (version 1)
  (deny default)
  (allow file-read*
    (subpath "~/Downloads")
  )
  (allow network-outbound
    (remote tcp "localhost:80")
  )

  (version 1)
  (allow default)
  (deny network*)

  # start an airgapped shell, and play around in there..
  sandbox-exec -p "(version 1)(allow default)(deny network*)" bash

There have been a few GitHub issues open but from what I can tell it's in the "not technically possible with V8 VM" category

Realistically I think they long ago should have been banned from npm, with all submissions deleted.

So what excuse do the people installing these packages have?

I'm relatively new to the world of node. Is there anything objectively wrong or should I say nefarious with that this Jon person is doing? I guess, what's the issue here, from your perspective, if he's creating package (that albeit are simple) but some some amount of utility?

In my view it is objectively wrong to create trivial npm packages yes. If we look at the npm ecosystem as a commons, that person is polluting it. Of course you could say it's namespaced to one account, so what's the harm? In my view, plenty:

- package searches will show these packages due to the inflated usage from transient deps.

- installs are slower due to the package noise.

- increased attack surface when they are used

- cultural normalization of throwaway packages

Probably more.

Each dependency causes work for any serious use. You got to check license, got to check for updates, risk supply chain attacks (package disappearing, package replaced with bad code, ...) etc. which causes longer term cost.

In addition abstraction of trivial checks, makes it harder to see the limitations of said routine. How well does it work on numeric strings? How well on large numbers where float properties cause issues?

This is the first time I'm hearing about this guy, but not sure why there's so much hate.

It looks like he came from a non-technical background, and is trying to make the language more noob friendly.

Compare the pair:

if isEven(n) { }

if (n % 2) == 0 { }

I guarantee you my wife would have no idea what the second snippet even means.

if !(n & 1) {} // rightmost bit(LSB) is always `true` for odd integers

For code golf purposes, ~n&1 works fine

// FIXME: This breaks on negative numbers on ones-complement machines

There's an argument to be made for writing functions like `isEven` and using them instead of n%2. There's an argument that the JS standard library, or other comprehensive util libraries like Lodash or Underscore should include these functions.

The problem here is introducing separate dependencies for each of these tiny functions. Dependencies are code that you haven't written, but are still your responsibility. For a lot of things, that's a good tradeoff: if you don't have the expertise in a specific area, or if you can offload work to a dependency that you trust, that's great. But for micro dependencies like this, it's usually a bad deal - you don't get anything in return (seriously, how hard is it to write your own isEven function?) but you have to rely on a third party to be secure, to not push anything accidentally broken, to not change the API, etc.

(I think it's also worth pointing out that your wife is not a paid programmer. Software development should be accessible, but this isn't the only goal, and I think it's reasonable to assume that most programmers either understand the n%2 idiom, or know enough to be able to find help on the subject.)

The hate is deserved. This person lacks ethics.

Most professions require some sort of degree or license before you get to practice it. If your wife wants to develop software, she should learn the basics. Especially when her code is included in larger projects and ecosystems.

I think the criticism comes from the fact it is hard to avoid driving over badly designed bridges or avoid wasteful dependencies in the Javascript ecosystem due to the way the package management is organised, and it is felt this specific person contributes a lot to that problem.

I have no knowledge of this person, but I often avoid Javascript and NPM for exactly that reason. I'm hopeful of Deno though to fix some of that mess.

You may not like it, but this is what 10x performance looks like

It seems very uncharitable to describe someone as a “spammer” because their philosophy on the proper size of units of code reuse is different from yours.

It seems overly charitable to me to frame the dispute in those terms. You and I might differ as to the appropriate amount of vermouth in a martini or pineapple on a pizza and I won't worry much about it, within reason.

There's a limit though! I think up to about 10% pineapple by weight is reasonable for a Hawaiian, if you choose 0 or 20% then we'll have no issue. If you went to 30% I don't think I could stop myself writing a libellous remark on hn. Anything about 50% and I would be morally forced to denounce you to the proper authorities. About 80% is where the nightmares begin.

At a certain point, isn't it just grilled pineapple with pizza crumbs?

Even if you think having a dependency load `is_even()` is a good thing, surely you can see how it's pretty hard to defend having a completely separate and nearly identical `is_odd()` rather than just `!is_even()`

The argument is that non-programmers like his wife don't understand e.g. `!`.

I think if you're installing npm packages and writing code you're a programmer whether you want to be or not.

> It seems very uncharitable to describe someone as a “spammer” because their philosophy on the proper size of units of code reuse is different from yours.

https://github.com/jonschlinkert/ansi-reset

https://github.com/jonschlinkert/ansi-bold

https://github.com/jonschlinkert/ansi-dim

https://github.com/jonschlinkert/ansi-italic

https://github.com/jonschlinkert/ansi-underline

https://github.com/jonschlinkert/ansi-inverse

https://github.com/jonschlinkert/ansi-hidden

https://github.com/jonschlinkert/ansi-strikethrough

https://github.com/jonschlinkert/ansi-black

https://github.com/jonschlinkert/ansi-red

https://github.com/jonschlinkert/ansi-green

https://github.com/jonschlinkert/ansi-yellow