When compiled to `GOOS=js`, wasm does not maintain the working directory: it is defined by the host. While not explicitly documented, `os.TestDirFSRootDir` in Go suggests the working directory must be valid to pass (literally the directory holding the file). This adds an experimental CLI flag that gives the initial working directory. This is experimental because while GOOS=js uses this, current WASI compilers will not, as they maintain working directory in code managed by wasi-libc, or as a convention (e.g. in Zig). It is not yet known if wasi-cli will maintain working directory externally or not. Signed-off-by: Adrian Cole <adrian@tetrate.io>
Overview
When GOOS=js and GOARCH=wasm, Go's compiler targets WebAssembly Binary
format (%.wasm).
Wazero's "github.com/tetratelabs/wazero/experimental/gojs" package allows you to run
a %.wasm file compiled by Go. This is similar to what is implemented in
wasm_exec.js. See https://wazero.io/languages/go/ for more.
Example
wazero includes an example that makes HTTP client requests.
Experimental
Go defines js "EXPERIMENTAL... exempt from the Go compatibility promise."
Accordingly, wazero cannot guarantee this will work from release to release,
or that usage will be relatively free of bugs. Moreover, [GOOS=wasi] will
happen, and once that's available in two releases wazero will remove this
package.
Due to these concerns and the relatively high implementation overhead, most will choose TinyGo instead of gojs.