[lvncelot]

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.

[spacechild1]

Check out this very useful utility: https://github.com/mitsuhiko/is-jonschlinkert :)

[password4321]

Possibly related: https://github.com/SukkaW/nolyfill vs. ljharb and nodejs 4

[runarberg]

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.

[Ataraxic]

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.

[wk_end]

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.

[runarberg]

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.

[Aeolun]

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.

[runarberg]

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.

[bryancoxwell]

I love the release notes:

> It exists.

[Levitz]

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.

[verandaguy]

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.

[fmx]

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?

[plufz]

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…

[fmx]

Ah yes, that actually explains a lot! Thanks.

[ncruces]

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

[tshaddox]

Here we are all talking about him now!

[peteradio]

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.

[umanwizard]

Is there any evidence that he has ever done anything like this, or that he plans to? Or is this just pure speculation?

[peteradio]

I didn't declare he's done this only that it is a vulnerability of depending on those packages.