multiple "registry" support about component HOT 24 CLOSED

suggestion from Patrick Mueller that I like was to explicitly state the registries in your root component.json etc instead of a dotfile

from component.

A really great feature would be if we could support accessing components from private GitHub repositories by using OAuth? That would make having private components really simple.

from component.

yeah that would be pretty cool

from component.

accessing private github repos would be rad, but the hassle of oauth isn't worth it. we wouldn't be able to automate this, would we? with selfhosted firewall-protected registries there are no issues with authentication and you could even use github enterprise. but that still isn't a good solution in all cases. you always have to have a registry running, even when developing privately. i like the idea to support git urls like npm oder bower does.

from component.

yeah that's what my gut says, oauth is really lame haha, it would be nice definitely, but it's also pretty GH specific, whereas the "username/project" portion is still specific but trivial to set up with only a file server

from component.

-1 to git urls though, we aren't even doing git clones, just fetching the files directly it's muuuuch faster

from component.

Yeh, I wouldn't want private repositories on GitHub to be instead of multiple registry support, but it would be a great extra feature. GitHub does support basic auth, which would be much easier than OAuth. I hadn't realised it was an option when I suggested OAuth.

from component.

ah cool, yeah basic would be much more reasonable

from component.

what if you need 2 private registries?
say both registries host packages

• dialog
• modal

Now you want dialog from A and modal from B. There is no way to get this work when you just have an registries array in your component.json.

In this case you would do sth like

registries: {
  'first': 'http://first/',
  'second': 'http://second/'
},
dependencies: {
  'first:ui/dialog': '*',
  'second:ui/modal': '*'
}

from component.

things will be much simpler with basic auth, you would just to type passwords on component install

from component.

Interestingly the raw links on the github website include an authentication token for private repositories, so that token could be used directly. Sadly there's no way to tell the difference between a private repository and one you just don't have access to so we'll need to have users be explicit about it so we know when to ask for username and password. perhaps a built-in private repository that could be used in the style @juliangruber suggests.

from component.

I guess that auth token is regenerated periodically or on demand so we can't rely on that.

from component.

Probably true

from component.

it would just be precedence:

registries: ['http://localhost:3001', 'http://localhost:3002']

"ui/dialog" does 3001 have it? nope check 3002, nope check github

from component.

the side effect of "magically" doing it that way with simple precedence is that say for example you were using component/calendar and you wanted to fix or add something quickly, you could simply pull it down to your local file server, make the changes, and automatically anything using component/calendar in your batch of components would get these changes

from component.

That would be awesome indeed! Although it would reduce the speed of downloading the components, especially if you use multiple registries.

from component.

yeah slight overhead for sure, it should be pretty minimal but i'll have to try it out with a few and see how it is, we can also implement #47 which will speed things up even more so it might not be a big deal

from component.

Yeh, falling through for multiple registry support would be great. We still need to be explicit about private repositories though.

from component.

I dont think so, at very worst just name it something weird / specific like mycompany/tip

from component.

The problem is just that we need a way to distinguish private components from non-existent/miss-spelt components so we know whether to error or prompt for username and password.

from component.

github should return propper response codes, 403 or 404, so that's no problem...if we want private repo support.

from component.

Github returns 404 instead, in an effort to keep the existence of the repository private I assume.

from component.

@tj of course, you would seldomly overwrite exact repositories so your proposal works perfectly

@forbes so sth like forbes@mycompany/dialog would be necessary. i'm tending more and more towards private registries over private repositories. the syntax is better and it's easier as soon as you have your registry set up. supporting both isn't so cool...

from component.

I still think we need both. There both absolute killer features and neither is especially difficult to implement. I was thinking private:mycompany/dialog because then two people in my company can consume the same component and be prompted for both username and password (which would both be different for different people)

from component.