2664b1eb62
During #425, @neilalexander gave constructive feedback that the API is both moving fast, and not good enough yet. This attempts to reduce the incidental complexity at the cost of a little conflation. ### odd presence of `wasm` and `wasi` packages -> `api` package We had public API packages in wasm and wasi, which helped us avoid leaking too many internals as public. That these had names that look like there should be implementations in them cause unnecessary confusion. This squashes both into one package "api" which has no package collission with anything. We've long struggled with the poorly specified and non-uniformly implemented WASI specification. Trying to bring visibility to its constraints knowing they are routinely invalid taints our API for no good reason. This removes all `WASI` commands for a default to invoke the function `_start` if it exists. In doing so, there's only one path to start a module. Moreover, this puts all wasi code in a top-level package "wasi" as it isn't re-imported by any internal types. ### Reuse of Module for pre and post instantiation to `Binary` -> `Module` Module is defined by WebAssembly in many phases, from decoded to instantiated. However, using the same noun in multiple packages is very confusing. We at one point tried a name "DecodedModule" or "InstantiatedModule", but this is a fools errand. By deviating slightly from the spec we can make it unambiguous what a module is. This make a result of compilation a `Binary`, retaining `Module` for an instantiated one. In doing so, there's no longer any name conflicts whatsoever. ### Confusion about config -> `ModuleConfig` Also caused by splitting wasm into wasm+wasi is configuration. This conflates both into the same type `ModuleConfig` as it is simpler than trying to explain a "will never be finished" api of wasi snapshot-01 in routine use of WebAssembly. In other words, this further moves WASI out of the foreground as it has been nothing but burden. ```diff --- a/README.md +++ b/README.md @@ -49,8 +49,8 @@ For example, here's how you can allow WebAssembly modules to read -wm, err := r.InstantiateModule(wazero.WASISnapshotPreview1()) -defer wm.Close() +wm, err := wasi.InstantiateSnapshotPreview1(r) +defer wm.Close() -sysConfig := wazero.NewSysConfig().WithFS(os.DirFS("/work/home")) -module, err := wazero.StartWASICommandWithConfig(r, compiled, sysConfig) +config := wazero.ModuleConfig().WithFS(os.DirFS("/work/home")) +module, err := r.InstantiateModule(binary, config) defer module.Close() ... ```
38 lines
1001 B
Go
38 lines
1001 B
Go
package examples
|
|
|
|
import (
|
|
"bytes"
|
|
"fmt"
|
|
"testing"
|
|
|
|
"github.com/stretchr/testify/require"
|
|
|
|
"github.com/tetratelabs/wazero"
|
|
)
|
|
|
|
// Test_Simple implements a basic function in go: hello. This is imported as the Wasm name "$hello" and run on start.
|
|
func Test_Simple(t *testing.T) {
|
|
stdout := new(bytes.Buffer)
|
|
hello := func() {
|
|
_, _ = fmt.Fprintln(stdout, "hello!")
|
|
}
|
|
|
|
r := wazero.NewRuntime()
|
|
|
|
// Host functions can be exported as any module name, including the empty string.
|
|
host, err := r.NewModuleBuilder("").ExportFunction("hello", hello).Instantiate()
|
|
require.NoError(t, err)
|
|
defer host.Close()
|
|
|
|
// The "hello" function was imported as $hello in Wasm. Since it was marked as the start
|
|
// function, it is invoked on instantiation. Ensure that worked: "hello" was called!
|
|
mod, err := r.InstantiateModuleFromCode([]byte(`(module $test
|
|
(import "" "hello" (func $hello))
|
|
(start $hello)
|
|
)`))
|
|
require.NoError(t, err)
|
|
defer mod.Close()
|
|
|
|
require.Equal(t, "hello!\n", stdout.String())
|
|
}
|