support URL in require()

[z3dev]

Comments from #245

Looking at the docs, include via URL isn't possible yet... Would it be possible to add it? It'd be amazingly handy for referencing a file on GitHub, Gist or similar. Obviously cross-origin could be a pain, but I think GitHub at least is ok from that point of view?

Any feature that allows either of the 2 options below is welcomed!

specifying more than one JS file in a URL (one file contains the main() function, other are helper libraries)
specifying one file in the URL, but that file can require() from other files in the same location

This would finally allow giving out URLs of objects you have made that uses lower level libraries, without requiring you to copy/paste the libraries into a single file, or forcing the use of node.js for the same task.

I do this kind of thing in the Espruino IDE - you can just do var baz = require("http://foo.bar/baz.js") if you want to (I know that's not very spec compliant, but it's really helpful).

CORS can bite you, but 99% of the time people are linking to GitHub, and in that case we detect the URL and just use GitHub's API to access the file directly.

Expected Behavior

const tire = require(‘http://github.com/user/tires.js’j

Actual Behavior

Not possible

Steps to Reproduce the Problem

1. Not available

Specifications

• Version: V2
• Platform: all
• Environment: all

[SimonClark]

I agree that this would be a powerful capability to add. I think to drive adoption of jscad means to build a community. Doing that means making sharing and discovering of jscad models and assets dead-simple, and empowering the community to develop mix-ins.

This seems like a better way enable some of that than anything I've come up with :)

Do we have a sense of how complicated it's likely to be. We need a custom version of require(), I guess

[z3dev]

Thinking a little further... over-loading 'require()' could be dangerous. If hacked then designs will be forever forced to use require(), and there's ES6 'import()' on the horizon.

Also, there's the whole issue of handling heiarchies of require() statements, both normal and URL based. UG.

We should allow advanced users to use more functionality within designs, such as promises. This would make almost everything possible.

[z3dev]

@SimonClark I have some hacking good news. I was able to change the core library to handle normal or async versions of main functions. This means that users can do most anything now as promises are possible, including promises that do network fetches, etc.

I just know that something else will break, so further testing is required.

[SimonClark]

Fantastic! I need to find some time to play with it. Got lots of ideas

[hrgdavor]

@z3dev downloading resources probably should go through different method other than require.
That way whatever direction goes for require/import for javascript dependencies, it does not have to break resource fetching.
And this could then make it easier to go in direction of supporting promises from main, and scripts that use external resources that need to be fetched async.

synchronous XHR is perfectly ok and allowed inside workers tho.