Live data from Hacker News

50% of new NPM packages are spam

blog.sandworm.dev

311–320 of 325 posts

Re: 50% of new NPM packages are spam

#311

Earlier quoted context omitted.

Yep! Of course, I think the game theory involved with this practice has been, at least at one point, more effective than having nothing to show at all. Normally, I don't toot my own horn, but I was one of the few who published packages that actually did something, and something that was fairly unique at the time (I won't necessarily say good!), and the projects I showed off to prospective employers were things I did…

> At the time, one could have probably gotten away most of the time with merely claiming to have published open-source code or showing off how you got some GitHub stars. In retrospect, I can't say much of my honest portfolio work did for me other than act as learning experiences. Cranking out a bunch of garbage code would have sufficed for showing that I had some "skill" for landing my first job. That's one of the re…

    That's one of the reasons we stopped considering bootcamp candidates.
If (a 72 point font size IF!) your company has low traffic, internal CRUD apps to build and maintain, bootcamp candidates are excellent value. Not everyone needs to be 10x.

Re: 50% of new NPM packages are spam

#313
post #156

Earlier quoted context omitted.

It's a good strategy. Suddenly spam costs money.

Does spam costing more money stop spam? Does it cost money per account, project, version? If I can make $100 from one victim, is this spam still profitable? What happens to the international developers who cannot easily get a payment method setup? Does a $10/m "identity verification" stop a nation state from using the platform to influence?

Fair argument. The spam fee should be proportional to the amount of spam rather than account or fixed monthly fee. Some kind of micropayment per spam item. Per repo, or per commit / per release in case of NPM?

Micropayments on internet have always proven difficult to implement. No silver bullets.

Re: 50% of new NPM packages are spam

#314

Earlier quoted context omitted.

> I hope we don't ever make money a barrier to open source. Then make some other very cumbersome proof. But it's still better to cut off half the world from open source than pollute the few large software repositories with spam, which would dissuade everyone everywhere from contributing eventually. There's no problem contributing to a library from anywhere it's just that you collaborate with someone who in turn can p…

I don't understand this obsession with solving everything with money. It doesn't event solve this problem, just because someone payed the fee doesn't mean their code is not spam. You can't keep the fee small enough and still dissuade spammers.

You can do reputation, or money, or some "proof of work". Or you can do all of them. But money is by far the easiest one to implement. You could e.g. either require the votes of 3 separate maintainers of packages totaling 100k downloads in order to upload a new package, or you could have a $10 fee.

The reason money is natural is because there is a cost associated with manually vetting all packages.

Re: 50% of new NPM packages are spam

#315

Earlier quoted context omitted.

I don't understand this obsession with solving everything with money. It doesn't event solve this problem, just because someone payed the fee doesn't mean their code is not spam. You can't keep the fee small enough and still dissuade spammers.

You can do reputation, or money, or some "proof of work". Or you can do all of them. But money is by far the easiest one to implement. You could e.g. either require the votes of 3 separate maintainers of packages totaling 100k downloads in order to upload a new package, or you could have a $10 fee. The reason money is natural is because there is a cost associated with manually vetting all packages.

Everything is easy if all you care about the KPIs your system performs well in. Making any system with money is easy if you don't care about equality or fairness.

Re: 50% of new NPM packages are spam

#316

Earlier quoted context omitted.

Dude I couldn't get a credit card in India, do you think a young person can easily get bitcoin? Its not that I was banned from getting it, its just that I couldn't afford it and getting it was really hard. Getting bitcoin, starting from fiat, is equally hard.

Woa woa, I never said bitcoin. I would never bring it up on HN, that's a recipe for downvotes.

You are not being as clever as you think you are.

Re: 50% of new NPM packages are spam

#318

Earlier quoted context omitted.

I wish they did reviews, but if half of the NPM packages are spam, that's still 172.000 legitimate NPM packages - per WEEK. That's not feasible to review. Are these new packages or version releases of existing packages as well? I think there's a market for a verified nodejs repository, where every package is reviewed, scanned and approved by a human + a heap of security tools. It wouldn't accept all updates of packag…

> I wish they did reviews If the package is hosted on Github, the number of stars is a good indicator of quality.

It is trivial to buy GitHub stars in bulk if needed.

Re: 50% of new NPM packages are spam

#319
post #221

Earlier quoted context omitted.

I wish they did reviews, but if half of the NPM packages are spam, that's still 172.000 legitimate NPM packages - per WEEK. That's not feasible to review. Are these new packages or version releases of existing packages as well? I think there's a market for a verified nodejs repository, where every package is reviewed, scanned and approved by a human + a heap of security tools. It wouldn't accept all updates of packag…

"RHEL" model for nodejs? Why not, but finding enough people willing to actually pay for it will probably be difficult

You'd be surprised. 3rd party dependencies are huge risk for enterprise.

Re: 50% of new NPM packages are spam

#320
post #294
post #140

Earlier quoted context omitted.

Yup for sure, 100%. Pulling in a library every time you don't know how to do something is a choice. Only pulling in dependencies that have 10,000 Github stars or are in every react Youtube video without evaluating alternatives is also a choice. I learned to be way more discriminating about npm libraries from a tech lead a few years ago, and to be honest it's one of the best lessons I've learned in a while.

But it is not a viable choice anymore to “not include this useful dependency, because its dependency tree is huge, so I will just rewrite it from scratch”, which is what practically happens in most cases. No one deliberately imports bullshit like leftpad on the root level. If you use react alone it will probably already make enough of a mess that windows’s file operations will take considerable time on your node_modu…

there are room between huge dep tree and rewriting everything, that's where we should aim

for leftpad, even if I know it's just an example, there's a native String#padStart, and else lodash is pretty small, most mainstream libs have few deps actually

Post reply on HN