Documentation
¶
Overview ¶
Package gojavm adapts zip's embedded JavaScript runtime (github.com/zap-proto/zip/js) to base's extruntime.Runtime SPI, so a manifest with `"runtime": "goja"` loads here. There is now exactly ONE goja engine in the Hanzo stack — zip's *js.JSRuntime — and base, cloud and every other zip consumer share it. gojavm is the thin extruntime projection of that engine: it owns manifest loading, TS/JSX/ESM bundling (esbuild, see transpile.go) and the JSON-bytes Invoke wire; the VM pool, host-fn registration and per-request VM isolation all live in zip/js.
This is the lightweight JS option — pure Go, no cgo, shares the host heap. Use it when you don't need a hard sandbox.
It sits alongside plugins/jsvm (the hook-style goja host for .base.js hook files). Extension directories with extension.json + runtime=goja go through here; hook files still go through jsvm. Collapsing jsvm onto zip/js as well is tracked separately — it needs base's host-API binds surface lifted into zip first.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func NewRuntime ¶
func NewRuntime() extruntime.Runtime
NewRuntime constructs a goja-backed extruntime.Runtime over [shared]. The engine is zip's *js.JSRuntime; require()/console/process are provided by zip's VM provisioning, so migrated TypeScript backends that `require(...)`, `console.log(...)` or read `process.env` run unchanged.
func Run ¶ added in v1.5.59
Run evaluates src as one function call. It satisfies extruntime.Runner.
A call is admitted only when the engine has a warm VM for it: a pool asked for more than it holds builds VMs past it, and every VM the engine is handed stays reachable for the life of the process. So the pool size is also the number of functions that run at once, and the rest wait here or leave with their ctx's error.
Types ¶
This section is empty.
Source Files