> Apparently Maven has 61.9M indexed packages.

Where did you see that number? Maven central says it has about 18 million [1] packages. Maybe with all versions of those 18 million packages there are about 62 million artifacts?

While the Java ecosystem is vastly larger, in Java (with Maven, Gradle, Bazel, etc.) it is not common to use really small libraries. So you end up with vastly less transitive dependencies in your projects.

[1] https://mvnrepository.com/repos/central

On Maven, I restrict packages to Spring and Apache. As opposed to NPM, where even big vendors can depend on hundreds of small ones.

There was a huge uproar about that guy specifically and deep dependency graphs in general a year ago. A lot has already changed for lots of the popular frameworks and libraries. Dependency graphs are already much slimmer. The cultural change is happening, but we can't expect it to happen all at once.

Irrelevant here. You use eslint-plugin-import with its 60 dependencies; One dependency or 60 is irrelevant because you only need one token: his. They're all his packages.

The problem with that guy is that the dependencies are useless to everyone except his ego.

That wouldn't be a problem if there was proper package signing and the polyfill packages were hosted under a package namespace owned by the javascript specification committee.

It's both that and a culture of installing a myriad of constantly-updating, tiny libraries to do basic utility functions. (Not even libraries, they're more like individual pages in individual books).

In our line-of-business .NET app, we have a logger, a database, a unit tester, and a driver for some specialty hardware. We upgrade to the latest version of each external dependency about once per year (every major version) to avoid accruing tech debt. They're all pinned and locally hosted, nuget exists but we (like most .Net developers) don't use it to the extent that npm devs do. We read the changelogs - all four of them! - and manually update.

I understand that the NPM ecosystem works differently from a "batteries included" .Net environment for a desktop app, but it's not just about where the users are. Line of business code in .Net and Java apps process a lot of important data. Slipping a malicious package into pypi could expose all kinds of juicy, proprietary data, but again, it's less about the existence of a package manager and more about when and how you use it.

We don't see these attacks nearly as severe or frequent on Maven, which is a much older package management solution. Maven users would be far more attractive targets given corporates extensively run Java.

It is also, in my humble but informed opinion, where you will find the least security concious programs, just because of the breadth of it's use and myriad of deployments.

It's the new pragmatic choice for web apps and so it's everyone is using it, from battle hardened teams to total noobs to people who just don't give a shit. It reminds me of Wordpress from 10 years ago, when it was the goto platform for cheap new websites.

Every NPM turd should be run with bubblewrap or a similar sandbox toolkit at least.

So do you expect other supply chain services that also supply juicy targets to be affected? I mean, we live in a bubble here in HN, so not seeing something in the front page doesn't mean it doesn't exist or it doesn't happen, but the feeling is that NPM is particularly more vulnerable than other services, correct me if I'm wrong.