Consider deprecating registry.yarnpkg.com?

[jamiebuilds]

Opening this to discuss moving to registry.npmjs.org now that they've moved to Cloudflare.

Assuming we want to deprecate the Yarn registry (which seems to be the correct assumption), we need a plan for how to do it because a lot of infrastructure now depends on it.

For starters, we can never ever get rid of registry.yarnpkg.com completely. We shouldn't break those systems that depend on it, and it costs nothing so why would we not just leave it in place permanently.

Also, we cannot switch the registry config over outside of a major version as there are many CI systems that whitelist registry.yarnpkg.com and would break if it was switched.

However, we can start recommending that people change their Yarn configs to the npm registry immediately and start outputting deprecation warnings. Then in Yarn 2.0 we can switch the default registry over.

We could also consider putting something inside yarn.lock which configures the preferred registry and for new yarn.lock files we can use the non registry.

[arcanis]

Edit I changed my view, cf below.

You have a valid point, now that npm moved to Cloudflare we can reasonably expect a speed improvement, so using our mirror isn't that important (I personally feel motivated when I see our little stat page going up, but I agree this isn't a reason to keep the thing around if it doesn't benefit the users).

However as you mentioned we'll always have to keep the registry around, so I don't think there's any hurry to change things now (which doesn't mean we'll keep using it by default forever, but right now I'd prefer to focus on other things).

What I think we should do:

• Implement for the v2 the mecanism that will allow us to remove the registry host from the lockfiles (yarn.lock should not include base registry(http://registry.npmjs.org) #3330). This is something we wanted to do anyway, so that's great! I'll move the task in the v2 project, and if someone wants to tackle this, let me know.

• Once people start using the v2, their lockfiles will be progressively rewritten to not contain any host. Then, in a later release (not necessarily a major one), we'll then be able to toggle the default registry without requiring any change to the lockfile itself.

[BYK]

Once people start using the v2, their lockfiles will be progressively rewritten to not contain any host. Then, in a later release (not necessarily a major one), we'll then be able to toggle the default registry without requiring any change to the lockfile itself.

I think this will still be a breaking change due to whitelisting in CI environments. Is there a good reason to keep the proxy?

[jamiebuilds]

Yeah, it doesn't matter what is in the yarn.lock, it will be a breaking change because in some CI environments requests to registry.npmjs.org will fail

[g-plane]

I have created a module to help us convert the registry of yarn.lock file: https://github.com/g-plane/convert-registry

[jaredbeck]

yarn 1.9.4 silently ignores yarn config

yarn config get registry
https://registry.yarnpkg.com
yarn upgrade
git diff -- yarn.lock
-  resolved "https://registry.yarnpkg.com/......
+  resolved "http://registry.npmjs.org/.....

Would be good it it produced output like "Hey, we are going to ignore your config"

[ngyikp]

@jaredbeck That seems to be #6259

[greggb]

@arcanis One of the best parts of Yarn is its separation from NPM. When the v5 shenanigans were hurting lots of us, Yarn was there to keep us productive. With another NPM outage today, that has taken Yarn down with it, is there any chance there could be a completely separate Yarn mirror?

I understand the benefits of having a single source of truth, but it also puts the entire ecosystem into a single point of failure.

The NPM registry could be periodically copied and then have redundant yarnpkg urls pointing to that copy. If the NPM registry goes offline for whatever reason there would be a recent-ish copy to continue pulling from until syncing is resumed.

[BYK]

@greggb - the solution to that problem is the offline mirror feature in Yarn. Otherwise it is simply not feasible to have a completely separate repo with fast replication and for free.

[greggb]

@BYK That's a reactive solution though, right? I would like to do some work today, but because I don't have the mirror setup it's too late.

Any feelings on a subscription service? I know I'd be willing to look into a supported yarn service if it creates an alternative for JS package management.

Edit: As far as I'm aware the offline mirror is also limited to packages one's already installed.

[BYK]

@greggb - offline mirror is a preemptive measure like backups or the mirror you are proposing. You just have to do it before a disaster happens 😊

I personally don't think we need a mirror under these circumstances and it would just be too costly to maintain without the help of a company like CloudFlare or Akamai. Even then, just the operational overhead and making sure that service stays alive is not easy as you can see from npm folks.

[greggb]

@BYK You definitely know better than me, thanks for explaining. Just always nice to have options :).

Going to go create an offline mirror for all the packages I may potentially want to install in the future 🤣

[arcanis]

I've updated the title to clarify that this was more a discussion than an action item. Given the way things are going and the relative uncertainty of the long term viability of npm I'm strongly in favor of keeping the registry CNAME up for the foreseeable future.

My arguments are:

• Should npm close the light, we would be able to redirect to a viable mirror (which mirror it would be isn't clear, it probably won't come from our team as we don't possess the resources to maintain one).
• As mentioned in the OP the Yarn registry will always be needed anyway, so changing the default for the sake of changing the default has little to no benefit.

I'll close this issue for now to avoid confusion (it's not the first time I see it referenced as a fact), feel free to keep discussing if you'd like.