Support loading files from GitHub repositories

[thomashoneyman]

Supersedes #194 and #181 and fixes #164. This PR:

1. Implements a new query parameter, github, which accepts a path to a source file in a GitHub repository and loads its contents.
2. Moves all examples from their various gists into this repository under the examples directory
3. Fixes the generics example to be compatible with PureScript 0.14
4. Updates the default example to link to the GitHub files in this repository instead of the gists.

I also updated the 0.14 package set we use as a few new packages have been added since the last update.

This is the last change necessary before we can release Try PureScript for PureScript 0.14, in my opinion.

[thomashoneyman]

I've tested and confirmed that this works as expected using the production build. I haven't been able to get the local dev server working properly, however -- I'm getting "Module Not Found" compilation errors for things that ought to be found, like import Effect. I'll confirm here that everything is fine with the dev server too once I can get that working.

[hdgarrood]

I think this ought to use a tag from some kind of configuration rather than hardcoding the branch name, so that we can change these without breaking the currently released version. In practice we will want this to be the tag from the current version.

[thomashoneyman]

Yea — I could thread this in as an argument to main, so that it can be accessed in various places taken from outside the PureScript code.

[hdgarrood]

Sounds good 👍

[thomashoneyman]

I could also do that with the entire dev / prod configurations in that case — thoughts?

[hdgarrood]

If that makes the overall setup simpler, sure, I don't see why not.

[thomashoneyman]

On second thought, doing this would require some kind of text replacement processing pass to work. After all, this example is code loaded literally into the Try PureScript editor.

Otherwise, we'd have to do something like read the current tag from data in the index.html file or something like that, but this would be user-visible code and I'm not a huge fan of that.

Another option is to manually hard-code the tag as part of the release process and document where the tag would need to be updated -- we release so infrequently that this feels legitimately like an option.

[hdgarrood]

True - I think manually hardcoding the tag and documenting that it needs updating will work.

[thomashoneyman]

Perhaps we should split the repository README so that the main README is for users and there's a separate development guide. It could include instructions for developing, like we already have, but could also have a release guide which includes:

• Updating the hardcoded tag
• Checking externs sizes
• Running the deployment

What do you think?

[thomashoneyman]

For now I've just added a note about the hardcoded tags to the README, but I think we probably do want a dedicated, separate development + release guide.