What is the difference from registry.npmjs?
Does it have some new Features?
It would be nice if there is an open source version of a yarnpkg registry server. so some one can set itsown private yarnpkg server.
PS:
As the Features describe:
supports mixing registries.
How to set this? Can i set different packages to different registrys by config file?
Right now it's just a reverse proxy to registry.npmjs.org
. This is to give us more flexibility in the future if we decide to customise the backend to work more efficiently with our client.
Is there any way to change which registry yarn points to by default? Our organization would love to use Yarn internally, but we have JFrog's Artifactory setup as an npm proxy and internal package store already. Being able to point Yarn towards our Artifactory instance would make for 100's of happier devs 馃槃
@obogobo yarn config set registry
@egoist seems to be the right command! doesn't quite work for us yet but it's probably on our end. Thanks!
I get how the abstraction of a reverse proxy allows for some future flexibility, but for now the extra layer adds an additional point of failure both for network reliability and also for DNS or infrastructure compromise.
Isn't it the case that the checksums that are checked against are also downloaded through registry.yarnpkg.org? So if your DNS or hosting is compromised, both packages and checksums could be modified to match.
The focus on offline/no-network/cached installs is a step forward for security in the NPM eco-system, but adding another point of failure and compromise to network installs is a step back.
If the checksums were downloaded directly from registry.npmjs.org while the code was downloaded through your reverse proxy, that would provide a cross-check against both services.
@egoist i still see 404 Not Found
after i set the registry using that command. using a private package on gemfury and their npm-proxy
Given the issue that arose today with the CloudFlare outage. I think we should chat about this again. It certainly seems like a case of nobody's fault, and certainly not yarn's. However this service seems at the least unnecessary, likely reducing performance adding another hop, and at worst a potential security vector.
Of course, I could edit the registry on my local, but I collaborate with lots of other developers on many projects. I (frankly) would rather not have my yarn.lock
file have a bunch of mismatched hosts in it or have to add a .yarnrc
to all my projects.
I think if yarn wants to start adding server-side helpers it can take advantage of there is some great potential benefits, but if there is nothing right now, why do we default to this proxy? We could always change the default later when that functionality is added.
EDIT: I found out this isn't a proxy but a CNAME. I don't think this changes anything though.
The flip side is that https://registry.yarnpkg.com/
is really helpful for me today as the main registry's fastly CDN has chosen to hate on me personally and bug out whenever I make any request :joy:
Is registry.yarnpkg.com
only a mirror, still? There's an edge case that only occurs when the mirror is used (instead of registry.npmjs.org
).
Most helpful comment
I get how the abstraction of a reverse proxy allows for some future flexibility, but for now the extra layer adds an additional point of failure both for network reliability and also for DNS or infrastructure compromise.
Isn't it the case that the checksums that are checked against are also downloaded through registry.yarnpkg.org? So if your DNS or hosting is compromised, both packages and checksums could be modified to match.
The focus on offline/no-network/cached installs is a step forward for security in the NPM eco-system, but adding another point of failure and compromise to network installs is a step back.
If the checksums were downloaded directly from registry.npmjs.org while the code was downloaded through your reverse proxy, that would provide a cross-check against both services.