add support for requiring any url

[Gozala]

While I do think github is awesome and very likely satisfying for most users it would be still unfortunate to tie due strictly to it. There has already being requests to support bit-bucket there are people who feel that gitorious is better alternative to github etc..

I would like to propose to make duo just compatible with URLs. For example require('my-lib.org/2.0/core") could be resoled to https://my-lib.org/2.0/core.js all the requirements in it could also be resolved relative to that URL or as an absolute URLs if they don't start with ..

This has following benefits:

1. This means that support for github or any other alternative hosting is built in and should be as simple as: require("raw.github.com/Gozala/method/v2.0.0").
2. This seems very much in harmony with ES6 modules where you just require urls.
3. This means there can a debug face module loader that does live loading without pre building a package.
4. This means url shortener services can be used to have nice names for libs, in fact duo could offer such shortening service too.

[stephenmathieson]

+1, as long as require('github-user/github-package') still works

[Gozala]

Yeah I think popular use cases could get some shortcuts. Maybe something like require("@user/package") for gihub. Support for others popular choices could also be added as require("bitbucket@user/package").

[wilmoore]

I like the idea; though I'd go with require("@raw.github.com/Gozala/method/v2.0.0") -- it's very curl-like either way.

[jonathanong]

what's with the @s? just be spec compliant and use actual URLs: https://raw.github.com/Gozala/method/v2.0.0/index.js

[Gozala]

@jonathanong I would really like to make all this work for node which is possible if we don't have require terms that don't include : character :)

[tobiastom]

I think it would be very important to add support for just plain ssh-based repositories. e.g. [email protected]:/my/repository. That would make me really consider this nice idea.

[Gozala]

@tobiastom on the other hand if my.server has some http frontend support for url's will already cover this use case.

As I mentioned earlier : character in the require string will prevent node support, without buying us much.

[matthewmueller]

I'm with @jonathanong here, I think we should just treat package resolution with normal urls.

The more I think about it, the more I'm hesitant to add node support. I think a separate project might be better or perhaps a duo plugin. I think it's reasonable to add browserify support, but I'd like Duo to remain server-side agnostic and I think if we go down this path, it will tie us to the node.js ecosystem. I guess it all depends on the implementation though.

[howardroark]

@matthewmueller I 100% agree with this train of thought, it makes so much sense long term.

Furthermore I think it would be wonderful if there was a tool that used a pattern schema to decipher between git, local files and http files and grab them appropriately. I was about to start playing with a similar idea here. I have another project that I am getting on the go that would use this tool (or one like it) at its core. Basically the idea to to pull files from anywhere and run them through a template engine.

P.S. The logo for duo is epic!

[tobiastom]

@Gozala Actually I don't really care how I can use it, that was just a idea.

I just think it is really important to be independent. From github, bitbucket or whoever is out there. I think it's excellent when duo will not limit itself into the node environment (like @matthewmueller said), so why do it with services?

Right now I cannot use duo because my stuff is not on github, bitbucket or anything else public.

[tobiastom]

After reading the comment about why the : is not supported I get the issue with my proposal. Why not remix the idea of private repositories from others.

I don't like it that it is no longer inside the project, so maybe add some stuff to the package.json:

"duoRepositories": [
    "[email protected]:~/"
]

my/repository fro above would resolve to [email protected]:~/my/repository. First check all private repositories, if there is nothing found, do the public ones.

Again, just an idea because I really like to use stuff that is not public.

[topherfangio]

Hi folks! Any update on this? I'm working with a company that is currently hosting a private bower repo full of packages in addition to a private git repo. It would be awesome if we could point directly to the git URL instead of having to use bower :-)

👍

[stephenmathieson]

@topherfangio it's on everybody's "wish list", but none of us seem to have any time for such things. :/

PRs are more than welcome though