Primarily, I end up basing this off of the types of libraries being developed for Javascript, and what kinds of articles and thought leaders JS developers tout as innovative.

So by looking at a tiny fraction of the 1 million+ npm libraries, and articles by a few dozen people on the internet, you are able to conclude that the

> vast majority of JS developers don't seem to be aware of the rest of the software universe

Forgive me if I dismiss this as business-as-usual JS bashing

There is a difference between arbitrary bashing and giving concrete points of concern. I would hope such criticism would not be dismissed out of hand.

What concrete points of concern? I don't see any...?

sure, it's just sampling.

For starters, developers in other language communities don't publish packages for single line functions.

That's a philosophical difference which says nothing of their understanding of the rest of the software universe.

I dislike the microdependencies and the "DRY-taken-to-the-extreme" stuff that the js community does but your argument does not hold up.

I beg to differ; witness the fibur[0] Ruby Gem. Written by Arron Patterson (@tenderlove) to show that using threads in Ruby is very easy. The Gem consists of this single line:

   Fibur = Thread

Of course, he did it as a joke, and it doesn't excuse the serious packages that NPM contains, but it does prove that other languages have single line packages.

[0] https://rubygems.org/gems/fibur

I cannot talk for all other languages but at least in Java

1)All packages that are published can never be unpublished or re-released from a different contributor

2)Packages are namespaced

3)Nobody downloads packages directly from the internet. You always use a proxy which in most companies has security scans.

4)There are no "local packages" (like the node_modules dir), so it is impossible for the checked out source code to override your own vetted and secure package.

Not directly related to the incident of the original post, but I was mindblown when I realized that you can unpublish npm packages

1) Same applies for npm (granted, this was only fixed after the left-pad incident, and npm was not the only language's registry to have that issue).

2) As mentioned elsewhere in this thread, npm supports namespaced packages, but they are not mandatory. There are other major languages' registries in same situation.

3) Can you back up 'nobody'. I would suspect a lot of companies don't use a proxy. Some JS teams also use an internal proxy for npm, but it is obviously additional infrastructure to setup/maintain which has a cost.

4) Never heard anyone raise this as a problem before.

> Not directly related to the incident of the original post, but I was mindblown when I realized that you can unpublish npm packages

You can't, with the exception of a 72 hour window, to allow for accidental publishing [1].

[1] https://www.npmjs.com/policies/unpublish

1) The fact that an incident actually forced something that Maven registry did since inception, doesn't actually reinfornce the original argument? (that JS developers did not look at what other languages were doing already)

2) Again, whoever thought that namespaces should be optional instead of required "doesn't seem to be aware of the rest of the software universe". Who took this decision? Why?

3) Do a survey on your own. Ask Java developers you know if they use Artifactory/Nexus in their job and note down the percentage. Then ask the same question to JS teams

4) Just because something hasn't been exploited yet, doesn't mean it shouldn't be fixed. By that definition if left-pad hadn't happened would you say that (unpublishing) packages has not been raised as a problem yet?

1) As I said, it was not just JS in this situation at the time, it also applied to other major registries like PyPi. So your point does not reinforce the original attack on JS developers. Congrats to Maven for getting this right.

2) Namespaces were added later. It wasn't "a decision to make them optional". Also check out for the discussion here as to how namespaces don't solve this issue, this point is largely moot.

3) I'm not the person blanket attacking a community. Or making unlikely assertions that "nobody" in the Java world installs direct from the internet.

4) Detail the exploit, otherwise this is FUD.

4) You work for a Linux distribution. You have several global npm modules already installed that are safe and secure. You download source code of a killer app in order to package it. You check the source code itself and it is safe. However you didn't realize that there was a local node_modules directory in the git repo that contains package foo-1.2.3 with replaced code that does bad things. That package overrides your global one. You ship a compromised app.

The above scenario is impossible with maven, because there is no concept of local modules. Only the "global" ones will be used when you package an app. So if you check just the source code and it is safe then everything is fine.

Sounds like your argument boils down to "check the source carefully", not "local modules are evil".

If the source was checked carefully, you'd notice a checked-in node_modules dir.

If you didn't check the source properly, you could install a module that seems like it'ss using a known package, but really is using its own malicious version of the global package.