feat: support fetch via async functions (#131)

Author: Guy Bedford

Makefile

@@ -20,12 +20,12 @@ lib/spidermonkey-embedding-splicer.js: target/wasm32-wasi/release/spidermonkey_e
 target/wasm32-wasi/release/spidermonkey_embedding_splicer.wasm: Cargo.toml crates/spidermonkey-embedding-splicer/Cargo.toml crates/spidermonkey-embedding-splicer/src/*.rs
 	cargo build --release --target wasm32-wasi
 
-lib/starlingmonkey_embedding.wasm: StarlingMonkey/cmake/* embedding/* StarlingMonkey/runtime/* StarlingMonkey/builtins/* StarlingMonkey/builtins/**/* StarlingMonkey/include/* | lib
+lib/starlingmonkey_embedding.wasm: StarlingMonkey/cmake/* embedding/* StarlingMonkey/runtime/* StarlingMonkey/builtins/* StarlingMonkey/builtins/*/* StarlingMonkey/builtins/*/*/* StarlingMonkey/include/* | lib
 	cmake -B build-release -DCMAKE_BUILD_TYPE=Release
 	make -j16 -C build-release
 	@cp build-release/starling.wasm/starling.wasm $@
 
-lib/starlingmonkey_embedding.debug.wasm: StarlingMonkey/cmake/* embedding/* StarlingMonkey/runtime/* StarlingMonkey/builtins/* StarlingMonkey/builtins/**/* StarlingMonkey/include/* | lib
+lib/starlingmonkey_embedding.debug.wasm: StarlingMonkey/cmake/* embedding/* StarlingMonkey/runtime/* StarlingMonkey/builtins/* StarlingMonkey/builtins/*/* StarlingMonkey/builtins/*/*/* StarlingMonkey/include/* | lib
 	cmake -B build-debug -DCMAKE_BUILD_TYPE=RelWithDebInfo
 	make -j16 -C build-debug
 	@cp build-debug/starling.wasm/starling.wasm $@
@@ -42,4 +42,4 @@ obj/builtins:
 clean:
 	rm -r obj
 	rm lib/spidermonkey-embedding-splicer.js
-	rm lib/spidermonkey_embedding.wasm
+	rm lib/starlingmonkey_embedding.wasm

README.md

@@ -100,6 +100,23 @@ await writeFile('test.component.wasm', component);
 
 The component iself can be executed in any component runtime, see the [example](EXAMPLE.md) for an end to end workflow in Wasmtime.
 
+### Async Support
+
+To support asynchronous operations, all functions may optionally be written as sync or async functions, even though they will always be turned into sync component functions.
+
+For example, to use `fetch` which requires async calls, we can write the same example component using an async function:
+
+```js
+export async function sayHello (name) {
+  const text = await (await fetch(`http://localhost:8080/${name}`)).text();
+  console.log(text);
+}
+```
+
+ComponentizeJS will automatically resolve promises returned by functions to syncify their return values, running the event loop within the JS component to resolution.
+
+This asynchrony is only supported for exported functions - imported functions can only be synchronous pending component-model-level async support.
+
 ### CLI
 
 ComponentizeJS can be used as a CLI from `jco`:
@@ -125,13 +142,13 @@ The default set of features includes:
 * `'stdio'`: Output to stderr and stdout for errors and console logging, depends on `wasi:cli` and `wasi:io`.
 * `'random'`: Support for cryptographic random, depends on `wasi:random`. **When disabled, random numbers will still be generated but will not be random and instead fully deterministic.**
 * `'clocks'`: Support for clocks and duration polls, depends on `wasi:clocks` and `wasi:io`. **When disabled, using any timer functions like setTimeout or setInterval will panic.**
+* `'http'`: Support for outbound HTTP via the `fetch` global in JS.
 
-Setting `disableFeatures: ['random', 'stdio', 'clocks']` will disable all features creating a minimal "pure component", that does not depend on any WASI APIs at all and just the target world.
+Setting `disableFeatures: ['random', 'stdio', 'clocks', 'http']` will disable all features creating a minimal "pure component", that does not depend on any WASI APIs at all and just the target world.
 
 Note that pure components **will not report errors and will instead trap**, so that this should only be enabled after very careful testing.
 
-Note that features explicitly imported by the target world cannot be disabled - if you target a component to a world
-that imports `wasi:clocks`, then `disableFeatures: ['clocks']` will not be supported.
+Note that features explicitly imported by the target world cannot be disabled - if you target a component to a world that imports `wasi:clocks`, then `disableFeatures: ['clocks']` will not be supported.
 
 ## Using StarlingMonkey's `fetch-event`
 

StarlingMonkey

@@ -910,15 +910,16 @@ impl JsBindgen<'_> {
             binding_name(&resource.func_name(fn_name), &iface_name)
         );
 
-        uwrite!(self.src, "\nexport function {binding_name}");
+        // all exports are supported as async functions
+        uwrite!(self.src, "\nexport async function {binding_name}");
 
         // exports are canonicalized as imports because
         // the function bindgen as currently written still makes this assumption
         let sig = self.resolve.wasm_signature(AbiVariant::GuestImport, func);
 
         self.bindgen(
             sig.params.len(),
-            &callee,
+            &format!("await {callee}"),
             string_encoding,
             func,
             AbiVariant::GuestImport,

crates/spidermonkey-embedding-splicer/src/bindgen.rs

@@ -34,7 +34,8 @@ pub fn splice(
     exports: Vec<(String, CoreFn)>,
     debug: bool,
 ) -> Result<Vec<u8>> {
-    let config = walrus::ModuleConfig::new();
+    let mut config = walrus::ModuleConfig::new();
+    config.generate_dwarf(true);
     let mut module = config.parse(&engine)?;
 
     // since StarlingMonkey implements CLI Run and incoming handler,