search

volojs / volo

Create front end projects from templates, add dependencies, and automate the resulting projects
https://volojs.github.io/
Other
1.41k stars 99 forks source link

Enterprise Github resolver #181

Closed gdborton closed 10 years ago

gdborton commented 10 years ago

The bulk of the extra code is the same as original github, some paths change for the enterprise version.

I haven't yet signed the CLA, but I figured I'd open this up to discussion.

jrburke commented 10 years ago

Thanks for looking into this! Is it just a different API end point URLs, but the exact same JSON returned?

Also, what if the user watches to fetch from two enterprise installations?

Would this approach work, something that just expands the URL syntax for github URLs to accommodate enterprise installations:

Normally, for github IDs, it looks like github:owner/repo/version. Maybe for github ones, a github:example.com:owner/repo/versionwould result in enterprise URLs that useexample.com` in them.

A user for a given dependency could then do volo add example.com/owner/repo. Search might need something else, maybe a -domain option.

That would also allow the code paths for search/auth and such to stay the same for the most part, less duplicated code, and allow more flexibility if the same volo installation deals with more than one enterprise endpoint.

gdborton commented 10 years ago

I haven't found anything different in the json that gets returned.

For the most part the url difference is the the rest routes begin with /api/v3 instead of the api subdomain, but there was at least one more difference in that the zip location was quite different.

return enterprise.apiUrl('_nodeload/' + ownerPlusRepo + '/legacy.zip/' + version);

I think github.com also supports _nodeload though.

You're approach looks like it should work, let me know if you want me to test anything.