Comment by pluma | Hacker News Reader

Comment by pluma | Hacker News Reader

Parent Full thread

When io.js merged back into node.js the following happened:

1. Node.js was abandoned and replaced with io.js.

2. Io.js was relabelled as node.js.

3. The node.js project was put under open governance via the creation of the Node Foundation.

This doesn't really compare to npm:

* The npm-cli's name is using npm Inc's trademark: giving it away would leave the company with no name or create unwanted ambiguity between npm Inc the company and npm-cli the (then) community-owned open source project unaffiliated with the company.

* Yarn does not share any source code directly with npm-cli, it's a complete reimplementation of a similar feature set. It's currently backed by a mirror of the npm registry but that's the extent of the overlap.

* The Node Foundation already exists and Yarn is already owned by the community. I could see Yarn joining the Node Foundation and the Node Foundation replacing its bundled dependency on the commercially owned npm-cli but even then npm Inc has nothing to contribute to the process.

Personally I would much rather see Yarn join the JavaScript Foundation because it speaks to the broader appeal of Yarn outside the traditional "Node community" and the politics involved in the latter and its close ties to npm Inc.

FWIW I consider the close ties between the Node project and npm Inc nothing more than a historical accident that has resulted in a conflict of interest that is overdue to be resolved by dropping npm-cli from the official releases.

Now that yarn is no longer distributed using npm (although it's still possible to install it that way) that seems more realistic than ever.

What replaces the npm registry, though? That's the reason that npm Inc. exists, not just stewardship of the CLI.

A decentralized repository of packages that anyone can help out maintain. Not entirely sure how, but I think that would be the ideal scenario.

Something like IPFS could perhaps be used for this. I think the biggest issue is probably access control. I.e. just releasing packages addressed by content isn't enough, because people generally depend on @whatever/left-pad and not 5b055a0b42f1c or whatever the hash may be. Real estate in a global name space means someone gets there first, so you'll need to consider how to deal with name squatters and the likes. With a centralized source like npm it's as easy as getting in touch with support (they're very good) but when no one knows the name space everyone owns the name space – makes it hard to make things "nice".

So I guess what I'm saying is that just storage isn't the tricky bit to distribute really, but having a global namespace is I guess.

well, you could depend on left-pad@5b055a0b42f1c, and the name doesn't really matter. Normally you would include that as require('left-pad') but if you have multiple versions, I don't see why require('left-pad@5b055a0b42f1c') couldn't be used. There is a tool for doing this in Golang already[0] and I've also done some experiments to get this to work in JavaScript[1]

- [0] https://github.com/whyrusleeping/gx

- [1] http://everythingstays.com

Back when the npm registry was really struggling with reliability (I believe because it was secondary to profit for Joyent) I was saying we needed a decentralized registry solution.

But right when that got some upvotes on r/node, within a few days isaacs had npm inc. going. And within a few weeks or months, the npm registry was pretty rock solid. And I have not had a single registry issue in forever.

And npm 4 works well, and I'm sure npm@5 works even better.

I still think it makes sense to have a decentralized repository and I guess its nice to have a non-commercial alternative to npm. But for me its not important anymore because npm is working really great now.

That's great to hear!

Reliability sure was tough in those days. npm wasn't secondary or tertiary or any-ary to Joyent. It was my nights and weekends project the whole time I was there, and IrisCouch generously donated infrastructure, which we pushed to its very limit once Nodejitsu acquired them.

Go does something like this, by referencing packages through Git url. Of course, 99% of packages you install are through Github, but that's not Go's fault. It has downsides, but its really a great and extensible system.

You can do the same thing with npm and yarn as well by referencing the git+https URL and a tag/branch/commit instead of a version number.

Yarn does not run a mirror of the registry. registry.yarnpkg.com is a pass-through domain to the npm registry. It allows them to collect stats about yarn usage but is not a mirror.

>resolved by dropping npm-cli from the official releases.

But that would break 7 years of documentation and tutorials, likely bad for newcomers and thus the ecosystem

Not to mention quite a few CI build pipelines.

FWIW it's trivial to install yarn already: https://yarnpkg.com/en/docs/install

NPM currently doesn't provide a standalone distribution as far as I can tell, but presumably they would offer one if they no longer had the luxury of being bundled with Node.

Since changes generally don't happen overnight I would expect a transitional period where Node still bundles npm-cli but npm Inc has the time to prepare a standalone distribution before yarn replaces npm-cli. Additionally downstream channels could decide to provide legacy packages containing both.

so npm has created a huge vendor lock-in and we should live with it?!

As with any vendor lock-in situation, decisions should be made based on cost/benefit

Perhaps you can help come up with a strategy that gracefully handles breakages and eventually results in dropping npm-cli

"The only reason God could create the world in six days is, He didn't have to worry about backward compatibility."

LOL

They probably need to do something like docker did.

Reply on news.ycombinator.com