Live data from Hacker News

Entropic – A Federated Package Manager for JavaScript

twitter.com

51–60 of 69 posts

Re: Entropic – A Federated Package Manager for JavaScript

#51
post #3
post #2

I don't believe yet another package manager is going to fix anything, more likely it'll take years to reach maturity, will be riddled with bugs until then, and have some serious fundamental issues on its own that will be revealed down the path, if it ever gains popularity. Don't fix it if it aint broke should be a motto for more developers. Settling for good enough prevents second system effects and retards immaturit…

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

Re: Entropic – A Federated Package Manager for JavaScript

#52
post #14
post #13

Earlier quoted context omitted.

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, becaus…

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

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

Re: Entropic – A Federated Package Manager for JavaScript

#54
post #22
post #2

I don't believe yet another package manager is going to fix anything, more likely it'll take years to reach maturity, will be riddled with bugs until then, and have some serious fundamental issues on its own that will be revealed down the path, if it ever gains popularity. Don't fix it if it aint broke should be a motto for more developers. Settling for good enough prevents second system effects and retards immaturit…

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

Re: Entropic – A Federated Package Manager for JavaScript

#55
post #3

Earlier quoted context omitted.

> 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 t…

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.

Re: Entropic – A Federated Package Manager for JavaScript

#56
post #55

Earlier quoted context omitted.

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 t…

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.

Re: Entropic – A Federated Package Manager for JavaScript

#57

Earlier quoted context omitted.

I am trying to understand why we make NPM such a big deal (and suddenly have all these projects born to solve the NPM problem) when people have solve the issue of a package repository already. C j Silverio's point (JSConf's talk [1]) was that is NPM's scale that makes it hard. Refs: 1: https://www.youtube.com/watch?v=MO8hZlgK5zc

To put some perspective on this, comparing Debian to npm: Number of packages: Debian has 172,000 packages for the most popular architecture, amd64. i386 has 24,000 packages. The rest have less than 500 each. npm recently broke a million packages. Download counts: I couldn't find numbers for Debian. npm served 11.2 billion downloads last week. (Debian numbers retrieved by https://popcon.debian.org/ , npm numbers from…

Partially self-inflicted since a normal JS project will redownload the same packages over and over again, hundreds of times throughout their existence.

Re: Entropic – A Federated Package Manager for JavaScript

#58

Earlier quoted context omitted.

I am trying to understand why we make NPM such a big deal (and suddenly have all these projects born to solve the NPM problem) when people have solve the issue of a package repository already. C j Silverio's point (JSConf's talk [1]) was that is NPM's scale that makes it hard. Refs: 1: https://www.youtube.com/watch?v=MO8hZlgK5zc

To put some perspective on this, comparing Debian to npm: Number of packages: Debian has 172,000 packages for the most popular architecture, amd64. i386 has 24,000 packages. The rest have less than 500 each. npm recently broke a million packages. Download counts: I couldn't find numbers for Debian. npm served 11.2 billion downloads last week. (Debian numbers retrieved by https://popcon.debian.org/ , npm numbers from…

Debian also has a repository model which allows the packages to be served by a static file server, because the dependency resolution is entirely client-side. Npm doesn't.

Re: Entropic – A Federated Package Manager for JavaScript

#60
post #43

Earlier quoted context omitted.

Much longer is, I guess, a matter of taste. For example the package name "go.uber.org/zap" [0] looks quite short to me. [0]: https://godoc.org/go.uber.org/zap Not to mention that short names get depleted eventually and one needs to use longer names then anyway (see npm namespaces).

Or even end up with low quality generic defaults for things like routing in react because someone got the default name of say the routing library.

Presumably, if you really want short names, a local hosts like config with aliased names would do the job just fine. This has the added benefit that everyone can have their own aliases.
Post reply on HN