Refactor reactor to reuse shared initialization from qjs.c Extract common initialization logic from qjs.c into reusable functions that can be shared with the WASI reactor build. This eliminates code duplication between main() and qjs_init_argv(), reducing the reactor file by 45%. Add qjs-common.h with public API: - QJSConfig struct for initialization options - qjs_config_init() / qjs_config_parse_args() for CLI parsing - qjs_setup_runtime() for module loader and promise tracker setup - qjs_apply_config() for loading std modules, includes, and eval - qjs_new_context() (formerly static JS_NewCustomContext) - qjs_eval_buf() / qjs_eval_file() / qjs_parse_limit() Changes to qjs.c: - Make eval_buf, eval_file, parse_limit, JS_NewCustomContext non-static - Add shared helper functions for runtime/context initialization - Guard main() with #ifndef QJS_NO_MAIN for reactor builds The reactor now uses these shared functions instead of duplicating the argument parsing and initialization code. This also removes the #include "qjs.c" hack that was used to access static functions. Signed-off-by: Christian Stewart <christian@aperture.us>

Refactor reactor to reuse shared initialization from qjs.c Extract common initialization logic from qjs.c into reusable functions that can be shared with the WASI reactor build. This eliminates code duplication between main() and qjs_init_argv(), reducing the reactor file by 45%. Add qjs-common.h with public API: - QJSConfig struct for initialization options - qjs_config_init() / qjs_config_parse_args() for CLI parsing - qjs_setup_runtime() for module loader and promise tracker setup - qjs_apply_config() for loading std modules, includes, and eval - qjs_new_context() (formerly static JS_NewCustomContext) - qjs_eval_buf() / qjs_eval_file() / qjs_parse_limit() Changes to qjs.c: - Make eval_buf, eval_file, parse_limit, JS_NewCustomContext non-static - Add shared helper functions for runtime/context initialization - Guard main() with #ifndef QJS_NO_MAIN for reactor builds The reactor now uses these shared functions instead of duplicating the argument parsing and initialization code. This also removes the #include "qjs.c" hack that was used to access static functions. Signed-off-by: Christian Stewart <christian@aperture.us>

Refactor reactor to reuse shared initialization from qjs.c Extract common initialization logic from qjs.c into reusable functions that can be shared with the WASI reactor build. This eliminates code duplication between main() and qjs_init_argv(), reducing the reactor file by 45%. Add qjs-common.h with public API: - QJSConfig struct for initialization options - qjs_config_init() / qjs_config_parse_args() for CLI parsing - qjs_setup_runtime() for module loader and promise tracker setup - qjs_apply_config() for loading std modules, includes, and eval - qjs_new_context() (formerly static JS_NewCustomContext) - qjs_eval_buf() / qjs_eval_file() / qjs_parse_limit() Changes to qjs.c: - Make eval_buf, eval_file, parse_limit, JS_NewCustomContext non-static - Add shared helper functions for runtime/context initialization - Guard main() with #ifndef QJS_NO_MAIN for reactor builds The reactor now uses these shared functions instead of duplicating the argument parsing and initialization code. This also removes the #include "qjs.c" hack that was used to access static functions. Signed-off-by: Christian Stewart <christian@aperture.us>

Add reactor initialization functions for module loader setup The WASI reactor build exports raw QuickJS C APIs, but setting up the module loader requires calling JS_SetModuleLoaderFunc2() with js_module_loader - a C function pointer that cannot be obtained or called from the host side (Go, JavaScript, etc). Without the module loader, dynamic import() fails. Add qjs_init_argv() to qjs.c which initializes the reactor with CLI argument parsing (like main() but without blocking in the event loop). This: - Creates runtime and context - Sets up the module loader via JS_SetModuleLoaderFunc2() - Sets up the promise rejection tracker - Parses CLI flags: --std, -m/--module, -e/--eval, -I/--include - Loads and evaluates the initial script file The functions are added to qjs.c (guarded by #ifdef QJS_WASI_REACTOR) rather than quickjs-libc.c because they depend on static functions in qjs.c like eval_buf(), eval_file(), parse_limit(), and JS_NewCustomContext(). Exported functions: - qjs_init() - Initialize with default args - qjs_init_argv(argc, argv) - Initialize with CLI args - qjs_get_context() - Get JSContext* for use with js_std_loop_once etc - qjs_destroy() - Cleanup runtime Example usage from host: qjs_init_argv(3, ["qjs", "--std", "/boot/script.js"]) while running: result = js_std_loop_once(qjs_get_context()) // handle result qjs_destroy() Signed-off-by: Christian Stewart <christian@aperture.us>

Use --export-dynamic instead of manual export list for WASI reactor Replace the long list of -Wl,--export=<symbol> flags with -Wl,--export-dynamic which automatically exports all symbols with default visibility. Since JS_EXTERN is defined as __attribute__((visibility("default"))), all public API functions are exported automatically. Only libc memory functions (malloc, free, realloc, calloc) still need explicit exports since they don't have default visibility in wasi-libc. This addresses review feedback about keeping export lists in sync manually and reduces the CMakeLists.txt WASI reactor section from ~80 lines to ~15 lines. Signed-off-by: Christian Stewart <christian@aperture.us>

Merge branch 'wasi-reactor-libc' 

Add QJS_WASI_REACTOR build target Added a WASI reactor build variant for QuickJS-ng that enables re-entrant execution in JavaScript host environments (browsers, Node.js, Deno, Bun). The standard WASI "command" model has a _start() entry point that blocks in an event loop until completion. This freezes the host's event loop, preventing queueMicrotask, setTimeout, DOM events, etc. from running. The reactor model instead exports functions that the host calls: - qjs_init() - Initialize empty runtime, returns 0 on success - qjs_init_argv(argc, argv) - Initialize with e.g. ["qjs", "--std", "script.js"] - qjs_eval(code, len, filename, is_module) - Evaluate JS code - qjs_loop_once() - Run one iteration of the event loop (non-blocking) - Returns >0: next timer fires in N ms - Returns 0: more microtasks pending, call again immediately - Returns -1: idle, no pending work - Returns -2: error occurred - qjs_poll_io(timeout_ms) - Poll for I/O and invoke read/write handlers - Separate from qjs_loop_once() so the host can call it only when I/O is ready - This avoids unnecessary poll() syscalls - the host knows when data is available - Required because qjs_loop_once() only handles timers/microtasks, not I/O - Returns 0: success, -1: error, -2: exception in handler - qjs_destroy() - Cleanup runtime - malloc/free - For host to allocate memory for argv/code strings The host controls scheduling by calling qjs_loop_once() and using setTimeout or queueMicrotask based on the return value. When stdin has data, the host calls qjs_poll_io() to trigger os.setReadHandler callbacks. Build: cmake -B build-reactor \ -DCMAKE_TOOLCHAIN_FILE=/path/to/wasi-sdk/share/cmake/wasi-sdk.cmake \ -DQJS_WASI_REACTOR=ON make -C build-reactor qjs_wasi_reactor Output: build-reactor/qjs.wasm See QJS_WASI_REACTOR.md for full design document. Signed-off-by: Christian Stewart <christian@aperture.us>

Add QJS_WASI_REACTOR build target Added a WASI reactor build variant for QuickJS-ng that enables re-entrant execution in JavaScript host environments (browsers, Node.js, Deno, Bun). The standard WASI "command" model has a _start() entry point that blocks in an event loop until completion. This freezes the host's event loop, preventing queueMicrotask, setTimeout, DOM events, etc. from running. The reactor model instead exports functions that the host calls: - qjs_init() - Initialize empty runtime, returns 0 on success - qjs_init_argv(argc, argv) - Initialize with e.g. ["qjs", "--std", "script.js"] - qjs_eval(code, len, filename, is_module) - Evaluate JS code - qjs_loop_once() - Run one iteration of the event loop (non-blocking) - Returns >0: next timer fires in N ms - Returns 0: more microtasks pending, call again immediately - Returns -1: idle, no pending work - Returns -2: error occurred - qjs_destroy() - Cleanup runtime - malloc/free - For host to allocate memory for argv/code strings The host controls scheduling by calling qjs_loop_once() and using setTimeout or queueMicrotask based on the return value. Build: cmake -B build-reactor \ -DCMAKE_TOOLCHAIN_FILE=/path/to/wasi-sdk/share/cmake/wasi-sdk.cmake \ -DQJS_WASI_REACTOR=ON make -C build-reactor qjs_wasi_reactor Output: build-reactor/qjs.wasm See QJS_WASI_REACTOR.md for full design document. Signed-off-by: Christian Stewart <christian@aperture.us>

Update wasi SDK to v29 Fixes quickjs-ng#1282

Update wasi SDK to v29 Fixes quickjs-ng#1282