-
Notifications
You must be signed in to change notification settings - Fork 5
Description
Summary
I'd like to add custom native Rust modules to the JS runtime without forking hyperlight-js-runtime. Currently the native module registry is internal and not extensible.
Use Case
Some operations are too slow in pure JavaScript. For example, DEFLATE compression is ~50-100x slower than native Rust, which can cause CPU timeouts on large inputs. I want to add native modules that run inside the same Hyperlight guest VM without maintaining a full fork of the runtime.
Desired Outcome
- Build a custom runtime binary that includes all default native modules (io, crypto, console, require) plus my own
- Use the same mechanism that upstream uses to declare native modules
- Automatically inherit new native modules when upstream adds them
Proposed Approach
-
Expose
hyperlight-js-runtimeas a library — add [lib] toCargo.tomlso custom runtimes can link against it -
Provide a
native_modules!macro that generates aNativeModuleLoader. The macro always chains to the upstream loader first, then checks additional modules:// Upstream uses: native_modules! { "io" => io::js_io, "crypto" => crypto::js_crypto, "console" => console::js_console, "require" => require::js_require, } // Extender uses (upstream modules are inherited automatically): native_modules! { "compression" => my_compression_module, }
The macro-generated loader delegates to
hyperlight_js_runtime::NativeModuleLoaderfor any module it doesn't recognize, so extenders automatically get all upstream modules without listing them. -
Build-time binary override — add an env var check in
hyperlight-js/build.rsso custom runtime binaries can be embedded instead of the default:HYPERLIGHT_JS_RUNTIME_PATH=/path/to/custom-runtime cargo build
Benefits
- Same macro used by upstream and extenders
- Extenders automatically inherit upstream modules via delegation
- Compile-time only — no runtime registration or mutation