> mostly irrelevant issues

95% of the talk is about why those issues aren't irrelevant. Care to respond to those?

I think 100% of these issues are irrelevant in practice, 99.9% of the time. Sure, there was that "left-pad" thing one time. Sometimes NPM is down briefly.

Otherwise, it's all ideology. Some people make money off of other people's work. NPM could turn evil. I don't care, at least not at this point. Wake me up when it becomes an actual problem in terms of "getting work done".

I also disagree with the characterization that NPM really "owns" or "controls" anything. If they did something really bad, they could get replaced fairly quickly. Therefore, it's unlikely they will.

It's interesting how you say

1) it takes really long to get a replacement of the ground (it's gonna be riddled with bugs etc)

2) wake me up when it's an actual problem

To me it seems like these two don't coexist well.. if it has become a "real" problem (whatever that means) then it'd appear that it'd already be too late to build a replacement solution, in your own logic.

> 1) it takes really long to get a replacement of the ground (it's gonna be riddled with bugs etc)

I never actually said that. It shouldn't take that long to get a package manager going. Also, there are already "alternative" package managers out there that one could switch to right now, should the need arise.

Most JavaScript-related threads I see on HN feature at least a handful of comments from people who will avow that e.g. the npm ecosystem is hot garbage. Seems to me that it is broke and needs fixed.

Works fine for me. Could be better, but 'broke' is a strong word for something I use heavily, daily, with very few problems. Of course HN users love to complain that the npm ecosystem is full of junk, but that's like complaining that most websites are junk. Just learn to find the good ones. Learn to identify high quality packages. Run it by someone more experienced if you're not sure. And if you really can't find a decent quality package that fulfils your requirements, then that's probably a sign your requirements are specific, so roll up your sleeves and write some code.

> Most JavaScript-related threads I see on HN feature at least a handful of comments from people who will avow that e.g. the npm ecosystem is hot garbage.

It's not the "NPM ecosystem" that's hot garbage, it's the Javascript ecosystem. There's a culture of creating micro-packages that have dozens of of often trivial transitive dependencies. With a lot of popular projects, one "npm install" dumps maybe hundreds of packages and thousands of files into a "node_modules" folder that you can't reasonably move out of your source directory. There's also a culture of breaking interfaces and configuration a lot. Many developers growing up in this ecosystem think this is the "normal" way to do things, thus compounding the problem for "future generations".

None of this has anything to do with NPM or the company that runs it. Some of it has to do with NodeJS, which isn't the same as NPM . Another package manager wouldn't solve any of these problems. In practice, NPM works fine 99.9% of the time. That's "good enough".

The main issue with it is that it's too good and successful, therefore it's too easy to publish whatever crap as your library or its dependencies.

That's not really a fault in the tool managing installation and publishing the library, its dependencies or managing the repository, providing the auditing system, script runner frontend and the other things npm does.

You could similarly argue github is hot garbage, because there are so many crappy projects hosted on it.

It is the fault of the tool though if previous versions of a package are mutable, indeed deletable.

That's a fault of npm - _the registry_'s policies, not of the package manager. You could do the same with most other popular package managers if you have control over the registry.

Sounds like you're agreeing with the Entropic people: https://twitter.com/bitandbang/status/1134872073896169472

Their approach is to create a different kind of registries, and inevitably they need a new client that supports them.

Yes, changing the registry model is key.

I'm not quite convinced by their federated approach though. It feels like its just spreading out the problems, and not really preventing them from happening, and in the worst case even creating new ones.

As pointed out in the talk, running a registry becomes expensive once it becomes popular. So now instead of 1 central registry (which I agree is not a good idea) needing to fund the hosting, you have maybe 10-100 federated registries, with each one of them needing to fund the hosting and coming up with different economic models around it.

I'm also not sure how they would really be able to ensure immutability of packages in a federated system. A node could simply publish two different packages with the same name and version number to different parts of the network. Yes, you can reduce the impact by saving an integrity hash in a lockfile, but npm already does that today.

> It is the fault of the tool though if previous versions of a package are mutable, indeed deletable.

The package-lock.json contains hashes to verify integrity.

For legal reasons, you can't really have packages that are immutable or undeletable. In practice, that's just not really a big deal.

Also, how do you solve the problem where a maintainer hands over control of the repository to some malicious actor? What if a maintainer gets hacked? Ultimately, you'd have to audit every single release of every package.

Again, despite those theoretical risks, despite the fact that Javascript projects often have thousands of dependencies, it all works out okay in practice.

It can and should be fixed in a backwards compatible way.

>Don't fix it if it aint broke should be a motto for more developers.

npm is broke, though. Better to have a replacement ready for when they finally go bang under the pressure of venture capitalism.

That's what I was about to say, that the current state of JavaScript package management is "broken" in certain aspects. The dependency on a private organization for open-source packages makes no sense.

I think it's a healthy sign that we're starting to see more npm alternatives, decentralized package management protocol/standards. After some churn, may the best ideas win!