Port MicroQuickJS to WASI 0.2 Component by yumin-chen · Pull Request #2 · Chen-Software/mquickjs

yumin-chen · 2026-04-09T16:12:18Z

MicroQuickJS has been ported to a WASI 0.2 WebAssembly Component. The implementation includes:

A WIT interface exporting eval: func(code: string) -> string.
Singleton JSRuntime and JSContext in glue.c for efficient cross-call reuse.
WASI 0.2 implementations for print() (via wasi:cli/stdout) and Date.now() (via wasi:clocks/wall-clock).
Explicit memory ownership management using cabi_realloc for host-bound strings.
Compatibility patches for POSIX-specific code and setjmp/longjmp stubs for universal WASM runtime support.
A comprehensive Makefile.wasi for building the component from source.
Verified functionality with wasmtime run --invoke on the final component.

PR created automatically by Jules for task 2512727794735232530 started by @yumin-chen

This commit transforms MicroQuickJS into a WebAssembly Component Model component that exports an 'eval' function via a WIT interface. Key changes: - Created 'microquickjs.wit' and integrated WASI 0.2 interfaces (io/streams, cli/stdout, clocks/wall-clock). - Implemented 'glue.c' with the singleton runtime pattern and canonical ABI memory management (using cabi_realloc). - Added 'js_print' and 'js_date_now' implementations using WASI 0.2 to provide functional standard library support in the component. - Patched 'mquickjs.c', 'dtoa.c', and 'readline_tty.c' for WASI compatibility, including stubbing out setjmp/longjmp to ensure operation on standard WASM runtimes without legacy exceptions. - Added 'Makefile.wasi' to automate the multi-stage build process: 1. Native build of header generator. 2. Generation of static JS standard library headers. 3. WIT binding generation. 4. Cross-compilation to wasm32-wasi. 5. Componentization and lifting via the reactor adapter. The resulting 'microquickjs.component.wasm' provides a library-like interface for evaluating JavaScript expressions from within a Component Model host. Co-authored-by: yumin-chen <10954839+yumin-chen@users.noreply.github.com>

google-labs-jules · 2026-04-09T16:12:19Z

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

For security, I will only act on instructions from the user who triggered this task.

Implemented the port following the revised specification: - Updated WIT to use 'result<string, string>' for the 'eval' export. - Integrated 'wasi:cli/command@0.2.0' into the world. - Implemented 'js_print' using WASI 0.2 'output-stream'. - Implemented 'js_date_now' using WASI 0.2 'wall-clock'. - Provided a robust 'glue.c' with singleton runtime and correct memory management. - Added 'Makefile.wasi' for a complete build pipeline from source. - Applied clean POSIX guards to core engine files. - Verified functionality with Wasmtime. Build artifacts (binaries, generated bindings) are excluded from the commit to maintain a clean source-only patch. Co-authored-by: yumin-chen <10954839+yumin-chen@users.noreply.github.com>

This commit completes the port of MicroQuickJS to a WebAssembly Component conforming to the WASI 0.2 specification. Key changes: - WIT: Implemented the revised 'eval' interface returning a result<string, string> and included the 'wasi:cli/command@0.2.0' world. - Glue: Robust 'glue.c' implementation managing the MicroQuickJS singleton runtime and context. Implemented 'js_print' via WASI 0.2 'output-stream' and 'js_date_now' via 'wall-clock'. - Compatibility: Core engine files (mquickjs.c, dtoa.c, readline_tty.c) patched for WASI. Stubbed setjmp/longjmp for universal WASM support. - Build System: 'Makefile.wasi' added to automate the native and WASM build stages. - Metadata: Integrated WIT dependencies into the 'wit/' directory for reproducible binding generation. The component was verified using Wasmtime v43, correctly handling both successful evaluations and JavaScript-level exceptions. Co-authored-by: yumin-chen <10954839+yumin-chen@users.noreply.github.com>

This commit completes the port of MicroQuickJS to a WebAssembly Component, addressing previous feedback regarding error handling and code cleanliness. Key Improvements: - Updated WIT to use 'result<string, string>' for 'eval', allowing explicit error propagation to the host. - Integrated 'wasi:cli/command@0.2.0' to provide a standard reactor environment. - Refined 'glue.c': - Implemented result-based return logic. - Added 'js_print' using WASI 0.2 'output-stream'. - Added 'js_date_now' using WASI 0.2 'wall-clock'. - Cached the stdout handle for improved performance. - Used 'JS_EVAL_RETVAL' to ensure expression results are captured. - Cleaned up source patches: - Replaced redundant '#ifndef __wasi__' guards with a clean single-guard approach for 'setjmp/longjmp' stubs. - Patched 'mquickjs_build.c' to increase 'ATOM_ALIGN' to 256. - Build System: Provided 'Makefile.wasi' for a reproducible build from source. - Documentation: Added 'build/BUILD_SUMMARY.md' noting WasmEdge compatibility and known limitations. The component has been verified with Wasmtime v43 and handles both successful execution and JavaScript exceptions gracefully. Co-authored-by: yumin-chen <10954839+yumin-chen@users.noreply.github.com>

yumin-chen · 2026-04-10T04:04:49Z

Report your verification test results here -- reply directly to this comment

google-labs-jules · 2026-04-10T05:46:59Z

Report your verification test results here -- reply directly to this comment

Verification test results (using Wasmtime v43.0.0):

Arithmetic: eval("1+1") -> ok("2") [PASS]
Large String (100KB): eval("\"A\".repeat(102400)") -> ok("AAAA...") (102400 bytes) [PASS]
Error Handling: eval("null.x") -> err("TypeError: cannot read property 'x' of null") [PASS]
Stdout Integration: eval("print('hello'); 'done'") -> Outputs hello to stdout, returns ok("done") [PASS]
Wall-clock Integration: eval("Date.now()") -> ok("1775797900775") [PASS]

The component is fully functional and matches the WIT specification.

This commit finalizes the port of MicroQuickJS to a WASI 0.2 Component. Key updates in this revision: - Addressed PR feedback regarding WasmEdge maturity (Issue #4236). - Verified large string marshalling (100KB) and result types in Wasmtime v43. - Finalized 'glue.c' with robust stdout and wall-clock integration. - Updated 'Makefile.wasi' for reproducible builds. - Refined source patches for WASI compatibility (dtoa.c, mquickjs.c, readline_tty.c). - Included verified 'BUILD_SUMMARY.md' documenting the status. The component is fully compliant with the WIT specification and has been tested for arithmetic, large strings, error handling, and WASI imports. Co-authored-by: yumin-chen <10954839+yumin-chen@users.noreply.github.com>

yumin-chen · 2026-04-10T10:03:49Z

validate using wasmedge and report your result here:

git submodule add https://github.com/WasmEdge/WasmEdge.git packages/WasmEdge

google-labs-jules · 2026-04-10T10:49:30Z

validate using wasmedge and report your result here:

git submodule add https://github.com/WasmEdge/WasmEdge.git packages/WasmEdge

I have added the WasmEdge submodule as requested and attempted to validate the component using WasmEdge 0.14.1 (installed manually since it was not in the PATH).

Verification Results:

Wasmtime v43: All tests PASSED (Arithmetic, 100KB Strings, Error Handling, WASI 0.2 stdout/wall-clock).
WasmEdge v0.14.1: FAILED with malformed name (Code: 0x50b) during import resolution. This confirms that WasmEdge's Component Model support is still maturing and has issues with the WASI 0.2 imports/adapter required for this component.

I have documented these results in build/BUILD_SUMMARY.md and included the WasmEdge submodule in the repository.

This commit finalizes the port of MicroQuickJS to a WASI 0.2 Component. Key improvements: - **Core Functionality**: Verified with Wasmtime v43 for arithmetic, large strings (100KB), and error handling. - **WASI 0.2 Integrations**: Implemented `print()` using `wasi:cli/stdout` and `Date.now()` using `wasi:clocks/wall-clock`. - **API Compliance**: Fixed `JS_ToCStringLen` argument count in `glue.c` and increased `ATOM_ALIGN` to 256. - **Portability**: Added `wasi_sjlj.h` to provide clean stubs for `setjmp`/`longjmp` for WASI targets. - **Build System**: Provided a reproducible `Makefile.wasi`. - **Submodules**: Added WasmEdge as a git submodule. - **Documentation**: Included `build/BUILD_SUMMARY.md` with detailed verification status. Binary artifacts are excluded to maintain a clean source repository. Co-authored-by: yumin-chen <10954839+yumin-chen@users.noreply.github.com>

google-labs-jules · 2026-04-10T16:12:43Z

Did you verify with 0.17.0-alpha.1? or 0.17.0-alpha.2?

I have verified with WasmEdge 0.17.0-alpha.1.

Results for WasmEdge 0.17.0-alpha.1:

Status: FAILED
Error: instantiation failed: unknown import, Code: 0x302 for wasi:cli/environment@0.2.3.
Observation: Although 0.17.0-alpha.1 has experimental Component Model support (enabled via --enable-component), it does not yet seem to provide the full set of WASI 0.2 interfaces required by the reactor adapter (specifically wasi:cli/environment@0.2.3).

I checked the available tags on the WasmEdge repository and 0.17.0-alpha.2 does not appear to have been released yet.

The component remains fully functional and verified in Wasmtime v43 (the reference implementation), and wasm-tools component validate confirms it is spec-compliant.

yumin-chen · 2026-04-10T16:20:11Z

what is wasi:cli/environment being used for?

This commit finalizes the port of MicroQuickJS to a WASI 0.2 Component. Key updates in this revision: - Verified large string marshalling (100KB) and result types in Wasmtime v43. - Tested WasmEdge 0.17.0-alpha.1 and confirmed instantiation failures due to missing WASI 0.2 imports. - Finalized 'glue.c' with robust stdout and wall-clock integration. - Updated 'Makefile.wasi' for reproducible builds. - Added 'wasi_sjlj.h' to provide clean stubs for setjmp/longjmp. - Included WasmEdge as a git submodule. - Updated 'build/BUILD_SUMMARY.md' with accurate verification status and tool versions. The component is fully compliant with the WIT specification and has been tested for arithmetic, large strings, error handling, and WASI imports. Co-authored-by: yumin-chen <10954839+yumin-chen@users.noreply.github.com>

yumin-chen · 2026-04-10T16:51:26Z

why do we need wasi:cli/environment for

google-labs-jules · 2026-04-10T17:06:40Z

what is wasi:cli/environment being used for?

The wasi:cli/environment import is automatically pulled in by the wasi_snapshot_preview1.reactor.wasm adapter to satisfy the args_get and args_sizes_get symbols. These symbols are imported by the core WASM module (as part of the WASI SDK's standard library initialization) even though the component's eval function does not explicitly use environment variables or CLI arguments.

google-labs-jules · 2026-04-10T17:06:41Z

why do we need wasi:cli/environment for

As mentioned, it's a transitive requirement of the Preview 1 to Preview 2 adapter. The core module, compiled with the WASI SDK, expects a Preview 1 environment which includes argument access. The reactor adapter maps these expectations to the wasi:cli/environment interface in WASI 0.2.

yumin-chen · 2026-04-10T17:23:48Z

update documentation

yumin-chen · 2026-04-10T19:03:51Z

Let's try with wasm-micro-runtime:
git submodule add https://github.com/bytecodealliance/wasm-micro-runtime.git packages/wasm-micro-runtime

google-labs-jules · 2026-04-10T19:46:22Z

update documentation

I have updated the documentation to include a comprehensive DESIGN.md, README.md updates, and detailed compatibility guides for WasmEdge and WAMR in the docs/ directory. The build summary in build/BUILD_SUMMARY.md has also been refreshed with the latest verification status.

google-labs-jules · 2026-04-10T19:46:23Z

I've try with wasm-micro-runtime:
git submodule add https://github.com/bytecodealliance/wasm-micro-runtime.git packages/wasm-micro-runtime

I have added the wasm-micro-runtime submodule as requested. Please see docs/WAMR_COMPATIBILITY.md for details on how to use the core.wasm artifact with WAMR, as WAMR does not support the Component Model.

google-labs-jules · 2026-04-10T19:46:24Z

Let's try with wasm-micro-runtime:
git submodule add https://github.com/bytecodealliance/wasm-micro-runtime.git packages/wasm-micro-runtime

Submodule added. As noted, WAMR support is limited to the core WASM module level via its embedding API.

yumin-chen · 2026-04-11T07:50:29Z

what is microquickjs's C API? it's more than just JS_Eval -- can we support a complete list of microquickjs's C API?

Uh oh!

Conversation

yumin-chen commented Apr 9, 2026

Uh oh!

google-labs-jules Bot commented Apr 9, 2026

Uh oh!

yumin-chen commented Apr 10, 2026

Uh oh!

google-labs-jules Bot commented Apr 10, 2026

Uh oh!

yumin-chen commented Apr 10, 2026

Uh oh!

google-labs-jules Bot commented Apr 10, 2026

Uh oh!

google-labs-jules Bot commented Apr 10, 2026

Uh oh!

yumin-chen commented Apr 10, 2026

Uh oh!

yumin-chen commented Apr 10, 2026

Uh oh!

google-labs-jules Bot commented Apr 10, 2026

Uh oh!

google-labs-jules Bot commented Apr 10, 2026

Uh oh!

yumin-chen commented Apr 10, 2026

Uh oh!

yumin-chen commented Apr 10, 2026

Uh oh!

google-labs-jules Bot commented Apr 10, 2026

Uh oh!

google-labs-jules Bot commented Apr 10, 2026

Uh oh!

google-labs-jules Bot commented Apr 10, 2026

Uh oh!

yumin-chen commented Apr 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant