Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Add Playground ability to import and use 3rd party packages. #26

Open
dmitshur opened this issue Jun 1, 2015 · 0 comments
Open

Comments

@dmitshur
Copy link
Member

dmitshur commented Jun 1, 2015

Abstract

Currently, the GopherJS playground allows one to import and use the standard Go library and a few select external packages (e.g., github.com/gopherjs/gopherjs/js). I propose we add support so that snippets can import and use all Go packages.

Background

The GopherJS playground today is capable and useful. It serves many different needs for different types of users.

  • Newcomers to GopherJS can try out simple snippets of Go code and see that it GopherJS actually works.
  • It is technically impressive - by existing - it conveys the message that GopherJS is written in Go, that it can self-host (compile itself using itself) and is actually useful by being able to run arbitrary snippets of Go code in your browser.
  • It can help answer the question if a certain piece of Go code is supported and compiles/runs.
  • It is also useful for people finding and reporting issues in GopherJS compiler, as they can often be reproduced in the playground.
  • Finally, it's helpful for general sharing of Go code via snippets, not unlike the official Go playground.

Proposal

I propose we expand the usefulness of the GopherJS playground, and also take advantage of its key strength - that the code is compiled and executed in the user's own browser (which is already a protected execution environment) and on their own computer, therefore minimizing the danger of malicious users trying to abuse, overload or exploit remote servers with arbitrary remote code execution. The GopherJS playground can perform some things that the Go playground is unable to, like make XHR requests to remote servers that have CORS enabled via net/http package. See example here.

Here's an example of such a prototype GopherJS playground that I created and tested locally:

image

The key usefulness of being able to import small 3rd party packages is that when working with local code, you often have various helpers you use for debugging or pretty printing. Whenever you want to share a piece of code, you often end up having to do extra work to factor these out or remove them. By allowing 3rd party packages to be imported, this becomes unnecessary.

Finally, I think it'd be really cool and a cool way to try out Go packages that you don't have locally, as well as test out if various Go packages will work okay with the GopherJS compiler.

Implementation

There are two ways to implement this that I've considered.

Initially, I was going to have a backend server that simply serves Go package source code (in a friendly way). The playground would ask for a Go package via an import path, and it would receive (over HTTP) a build.Package with a build.Context that allows it to be built and used.

Another approach, as I've realized when I started implementing this, is to use GopherJS compiler to compile requested Go packages on the server, and simply serve the output .a.js archive file. The backend server would need to compile the Go packages via GopherJS. No arbitrary user code needs to execute on the backend server, it only needs to be compiled. In this case, the frontend changes are very minimal, as nothing changes except the sources where .a.js archive files are loaded from (previously, it was only statically available ones in the pkg folder).

In both cases the backend server would need to be able to fetch Go packages on demand. I already have much of this functionality done, e.g., it was needed for gotools.org to operate.

Discussion

Primarily, I'm interested in hearing people's thoughts on this. Is this an exciting, desired addition? Or is it unwelcome and unwanted?

I can volunteer to implement and host the backend component to make this possible, as well as frontend changes (of course, I welcome collaboration and help too), if this feature is wanted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant