For the benefit of others who need to run jsonnet through a web browser, here's a series of steps I've used to get a usable browser version:
3) Open a command line that has access to go
5) Navigate the command line to the go-jsonnet directory
6) Run: GOOS=linux gopherjs build ./cmd/jsonnet
- This should generate 'jsonnet.js' and 'jsonnet.js.map'. The GOOS tag may be unneeded on some systems.
7) Modify the end of `jsonnet.js` - the last few lines should look like this:
$go($mainPkg.$init, []);
$flushConsole();
}).call(this);
//# sourceMappingURL=jsonnet.js.map
Replace that with the following:
var $global = this;
$global.jsonnetPackage.$init();
$global.jsonnet = $global.jsonnetPackage.MakeVM();
}).call(this);
//# sourceMappingURL=jsonnet.js.map
This will give direct access to the jsonnet package, and a prepared VM that can be used globally. Try `jsonnet.EvaluateSnippet(filename, snippet)`, or for different operations, use `jsonnetPackage.SnippetToAST(filename, snippet)`. Alternately, export the entirety of $packages for deeper (but more manual) access.
Note: I make no claim that this is the best way to do this. It's quick and it makes readable code, but it's not a good build process.
It's possible Gopher isn't even the right tool - it refuses to export a package as a library, opting instead to run a single entry point on-load. It builds every package in a way that's fully usable in a browser - it just won't expose them.
An solution that uses Gopher would be to write a library interface that manually exports each object and method. This is not easy to write in Gopher, though. A naive approach of assigning the constructors to global variables had negative results; none of the object bindings made it through, and it was overall much less usable than just pulling the $packages list out of the compiled source.
Another solution might be compiling through the now-abandoned jsgo.io; it's designed specifically to make packages into single exports, and it has a local version. I was not able to get it to install, however.