[jammi]

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.

[kitd]

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

[hobofan]

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.

[icebraining]

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.

[hobofan]

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.

[gridlockd]

> 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.

[xiphias2]

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