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