Hacker News Reader

Comment by rtpg | Hacker News Reader

I think on the first point, we have to start calling out authors of packages which (IMO) have built out these deptrees to their own subpackages basically entirely for the purpose of getting high download counts on their github account

Like seriously... at 50 million downloads maybe you should vendor some shit in.

Packages like this which have _7 lines of code_ should not exist! The metadata of the lockfile is bigger than the minified version of this code!

At one point in the past like 5% of create-react-app's dep list was all from one author who had built out their own little depgraph in a library they controlled. That person also included download counts on their Github page. They have since "fixed" the main entrypoint to the rats nest though, thankfully.

https://www.npmjs.com/package/has-symbols

https://www.npmjs.com/package/is-string

https://github.com/ljharb

View on HN

> entirely for the purpose of getting high download counts on their github account

Is this an ego thing or are people actually reaping benefits from this?

Anthropic recently offered free Claude to open source maintainers of repositories with over X stars or over Y downloads on npm. I suppose it is entirely possible that these download statistics translate into financial gain...

I've seen people brag about it in their resumes, so I assume it helps them find (better paying?) work.

I'm completely apathetic about spicy autocomplete for coding tasks and even I wonder which terrible code would be worse.

The guy who wrote is even/odd was for ages using a specifically obscure method that made it slower than %2===0 because js engines were optimising that but not his arcane bullshit.

Yes, there's definitely a financial gain aspect here. Tidelift provides $50/month for each of these packages. https://tidelift.com/lifter/search/npm/has-symbols

The incentives are pretty clear: more packages, more money.

Yes.

https://github.com/A11yance/axobject-query/pull/354

https://github.com/A11yance/aria-query/pull/497

from a security perspective this is even worse than it looks. every one of those micro packages is an attack surface. we just saw the trivy supply chain get compromised today and thats a security tool. now imagine how easy it is to slip something into a 7 line package that nobody audits because "its just a utility." the download count incentive makes it actively dangerous because it encourages more packages not fewer.

https://immich.app/cursed-knowledge

> There is a user in the JavaScript community who goes around adding "backwards compatibility" to projects. They do this by adding 50 extra package dependencies to your project, which are maintained by them.

> 6/28/2024

I remember seeing this one guy who infiltrated some gh org, and then started adding his own packages to their dependencies or something to pad up his resume/star count.

Really escapes me who it was.

https://github.com/A11yance/axobject-query/pull/354

https://github.com/A11yance/aria-query/pull/497

yes! this.

Christ. What a psycho.

As usual, there's a cultural issue here. I know it's entirely possible to paste those seven lines of code into your app. And in many development cultures this will be considered a good thing.

If you're working with Javascript people, this is referred to as "reinventing the wheel" or "rolling your own", or any variation of "this is against best practice".

I think the fact that everyone cites the same is-number package when saying this is indicative of something though.

Like I legit think that we are all imagining this cultural problem that's widespread. My claim (and I tried to do some graph theory stuff on this in the past and gave up) is that in fact we are seeing something downstream of a few "bad actors" who are going way too deep on this.

I also dislike things like webpack making every plugin an external dep but at least I vaguely understand that.

Have you heard of the left pad incident?

The problem is not imagined.

Even there the "problem" was left-pad being used by one or two projects used in "everything".

So the problem isn't that everyone is picking up small deps, but that _some_ people who write libs that are very popular are picking up small deps and causing this to happen.

This is different because it doesn't really say that all JS developers are looking to include left-pad. But I _do_ think that lots of library authors are too excited to make these kinds of dep trees

The problem I think is that the js community somehow thinks that being on npm is some bastion of good quality.

Just as the cloud is simply someone else's computer, a package is just someone else's reinvented wheel.

The problem is half the wheels on npm are fucking square and apparently no one in the cult of JavaScript realises it.

The point isn't that everyone needs to write the same code manually necessarily. It's that an author could easily just combine the entire tree of seven line packages into the one package the create-react-app uses directly. There's no reason to have a dozen or so package downloads each with seven lines of code instead of one that that's still under under a hundred lines; that's still a pretty small network request, and it's not like dead code analysis to prune unused functions isn't a thing. If you somehow find yourself in a scenario where you would be happy to download seven lines of code, but downloading a few dozen more would be an issue, that's when you might want to consider pasting the seven lines of code manually, but I honestly can't imagine when that would be.

The article and (overall) this comments section has thankfully focused on the problem domain, rather than individuals.

As the article points out, there are competing philosophies. James does a great job of outlining his vision.

Education on this domain is positive. Encouraging naming of dissenters, or assigning intent, is not. Folks in e18e who want to advance a particular set of goals are already acting constructively to progress towards those goals.

People aren't criticizing the development philosophy in this subthread. This has been done by the article itself and by several people before.

What people are criticizing is the approach in pushing this philosophy into the ecosystem for allegedly personal gain.

The fact that this philosophy has been pushed by a small number of individuals shows this is not a widespread belief in the ecosystem. That they are getting money out of the situation demonstrates that there is probably more to the philosophy than the technical merits of it.

This is a discussion that needs to happen.

Reminder this user is paid per download https://github.com/A11yance/axobject-query/pull/354#issuecom...

Hat tip to Sindre who has fifty bagillion packages but few of them depend on more than one of his other packages.

As usual, he's copying someone else who's been doing this for years:

https://www.npmjs.com/package/is-number - and then look and see shit like is odd, is even (yes two separate packages because who can possibly remember how to get/compare the negated value of a boolean??)

Honestly for how much attention JavaScript has gotten in the last 15 years it's ridiculous how shit it's type system really is.

The only type related "improvement" was adding the class keyword because apparently the same people who don't understand "% 2" also don't understand prototypal inheritance.

To be fair, prototypal inheritance is relatively uncommon language design. I'd rank it as considerably harder to understand than the % operator.

That's a good point, it's only been around for 30 years, and used on 95% of websites. It's not really popular enough for a developer to take an hour or two to read how it works.

The word "used" is doing some heavy lifting there. Not all usage is equal, and the fact that it's involved under the hood isn't enough to imply anything significant. Subatomic physics is used by 100% of websites and has been around for billions of years, but that's not a reason to expect every web developer to have a working knowledge of electron fields.

Fair point.

Let's compromise and say that whoever is responsible for involving (javascript|electron fields) in the display of a website, should each understand their respective field.

I don't expect a physicist or even an electrical engineer or cpu designer to necessarily understand JavaScript. I don't expect a JavaScript developer to understand electron fields.

I do expect a developer who is writing JavaScript to understand JavaScript. Similarly I would expect the physicist/etc to understand how electrons work.

The issue with this framing is that understanding something isn't a binary; you don't need to be an expert in every feature of a programming language to be able to write useful programs in it. The comment above describing prototypical inheritance as esoteric was making the point that you conflated the modulus operator with it as if they're equally easy to understand. Your responses don't seem to indicate you agree with this.

It sounds like you expect everyone to understand 100% of a language before they ever write any code in it, and that strikes me as silly; not everyone learns the same way, and some people learn better through practice than by reading about thinks without practice. People sometimes have the perception that anyone who prefers a different way of learning than them is just lazy or stupid for not being able to learn in the way that they happen to prefer, and I think that's both reductive and harmful.

Given that they literally changed the language to support the class keyword, I think we can safely assume it isn't just the beginners who never bothered to learn how prototypical inheritance works.

Reply on news.ycombinator.com