New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecating registry.yarnpkg.com #5891

Open
jamiebuilds opened this Issue May 26, 2018 · 11 comments

Comments

Projects
None yet
7 participants
@jamiebuilds
Copy link
Contributor

jamiebuilds commented May 26, 2018

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

This comment has been minimized.

Copy link
Member

arcanis commented May 26, 2018

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 (#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 BYK added this to the Yarn 2.0 milestone May 26, 2018

@BYK BYK added this to To do in Yarn 2.0 via automation May 26, 2018

@BYK BYK self-assigned this May 26, 2018

@BYK

This comment has been minimized.

Copy link
Member

BYK commented May 26, 2018

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?

@arcanis arcanis removed this from To do in Yarn 2.0 May 26, 2018

@arcanis arcanis removed this from the Yarn 2.0 milestone May 26, 2018

@jamiebuilds

This comment has been minimized.

Copy link
Contributor

jamiebuilds commented May 26, 2018

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

@Andarist Andarist referenced this issue Jun 18, 2018

Merged

No duplicated ast nodes #730

2 of 3 tasks complete
@g-plane

This comment has been minimized.

Copy link
Contributor

g-plane commented Jun 22, 2018

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

@jaredbeck

This comment has been minimized.

Copy link

jaredbeck commented Aug 30, 2018

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

This comment has been minimized.

Copy link

ngyikp commented Sep 1, 2018

@jaredbeck That seems to be #6259

@greggb

This comment has been minimized.

Copy link

greggb commented Sep 1, 2018

@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

This comment has been minimized.

Copy link
Member

BYK commented Sep 1, 2018

@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

This comment has been minimized.

Copy link

greggb commented Sep 1, 2018

@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

This comment has been minimized.

Copy link
Member

BYK commented Sep 1, 2018

@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

This comment has been minimized.

Copy link

greggb commented Sep 1, 2018

@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 🤣

yan12125 added a commit to yan12125/buildbot that referenced this issue Sep 1, 2018

Move from yarn registry to the npmjs one
registry.yarnpkg.com is going to be deprecated [1]

[1] yarnpkg/yarn#5891

@yan12125 yan12125 referenced this issue Sep 1, 2018

Merged

Move from yarn registry to the npmjs one #4291

1 of 3 tasks complete

splincode added a commit to splincode/store that referenced this issue Oct 21, 2018

@splincode splincode referenced this issue Oct 21, 2018

Merged

fix(store): deprecating registry.yarnpkg.com #613

3 of 3 tasks complete

splincode added a commit to ngxs/store that referenced this issue Oct 21, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment