Decide on API for github.com/gopherjs/gopherjs/build

[myitcv]

For module support, GopherJS needs to use the go tool under the hood (strictly speaking we could sit GopherJS atop go/packages to make it build tool agnostic, but we haven't done that for now).

But the Playground (https://gopherjs.github.io/playground/) runs github.com/gopherjs/gopherjs/build in-browser. Hence it does not have the go tool available. The Playground is, however, limited to standard library imports.

jsgo is more advanced in that it can handle non-standard library imports.

Hence in its most basic form we need to make github.com/gopherjs/gopherjs/build be driven by some sort of "driver" that knows how to resolve import paths (in some context). The simplest way to do that will be to provide an implementation of the following interface:

type Resolver interface {
    Load(conf *Config, patterns ...string) ([]*Package, error)
}

The Package type here is a cut-down version of https://godoc.org/golang.org/x/tools/go/packages#Package that will also have a field:

Open(path string) (ReadSeekCloser, error)

for subsequently opening files listed in the Package.

where:

type ReadSeekCloser interface {
    io.Reader
    io.Seeker
    io.Closer
}

This is, in effect, the last remaining piece of work to bring full module support to GopherJS. Given the command line version of GopherJS works just fine as of https://github.com/myitcv/gopherjs/tree/f5b96be2a04cf73ef5198ad6520e80375fd9764b, we could decide to leave github.com/gopherjs/gopherjs/build as broken for now, merge the command line module support upstream and revisit at a later date. This would be at the cost of the playground which would be stuck on Go 1.11.5.

Any thoughts/contributions on the above welcome.

cc @hajimehoshi @paralin @dave @dmitshur

[dmitshur]

Since this issue is about the github.com/gopherjs/gopherjs/build API, it should be in the https://github.com/gopherjs/gopherjs/issues tracker. Do you mind moving it there?

we could decide to leave github.com/gopherjs/gopherjs/build as broken for now, merge the command line module support upstream and revisit at a later date. This would be at the cost of the playground which would be stuck on Go 1.11.5.

Given our limited resources (per https://github.com/gopherjs/gopherjs/issues/894), I think this is a viable cost-cutting measure to take.

The way I see it, it's a limitation of the upstream Go project. Before modules, go/build was the canonical package to gather information about Go packages. After modules, golang.org/x/tools/go/packages became that. go/build did not require the use of exec.Command which allowed the GopherJS compiler to be compiled to JS (via itself) and the GopherJS Playground as we know could exist. When migrating to module mode, it requires the use of golang.org/x/tools/go/packages which in turn requires support for exec.Command that the GOARCH=js environment does not support. Therefore the GopherJS Playground cannot exist as is.

We can consider alternatives to make it work, such as:

• coming up with our own API, as you mentioned here
• changing the GopherJS Playground so that it performs Go compilation on the backend (on a server) rather than in the frontend (in the user's browser)
• consider pointing to jsgo as an alternative

However, I don't think the GopherJS Playground working as it does today should block GopherJS gaining support for modules. I think we should add module support, and work on the GopherJS Playground orthogonally (if anyone has time left to do so, otherwise it will stay at 1.11.5 until someone does).

[dave]

consider pointing to jsgo as an alternative

The jsgo compiler and playground will have exactly the same limitations. The jsgo compiler does compilation server-side, but it does it all in-memory. It would need significant changes to work with x/tools/go/packages. The jsgo playground does compilation server-side and also client side, so would similarly need a lot of work.

[paralin]

Please try not to change the call signature of gopherjs/build.