Repository navigation
Go GOOS=js wasm: runtime init panics on incomplete node shims (process/path/fs.constants) #18
Description
After #17 (live mem.buffer aliasing + TextDecoder DataView support), a Go
GOOS=js GOARCH=wasm module boots through syscall/js and reaches its program
init, but then panics:
panic: syscall/js: call of Value.Get on undefined
goroutine 1 [running]:
syscall/js.Value.Get(...)
Instrumenting syscall/js.valueGet shows the property-access sequence right
before the panic:
Object, Array, process, path, fs, constants, Uint8Array
i.e. Go's runtime/os init reads globalThis.process, globalThis.path,
globalThis.fs, then fs.constants — one of these (or a member such as
fs.constants) is undefined, so the next .Get panics.
This is node-shim completeness, not the WASM runtime — the live-memory and
TextDecoder fixes in #17 are what get execution this far. To run Go modules,
QuickBEAM's node API surface needs the globals/members Go's wasm_exec.js
expects (process, path, a fs exposing constants, …), or
wasm_exec.js's own fallback shims need to be reachable.
A 12 MB Go signer module reproduces it. Filed from the work fork
ZenHive/quickbeam; the two
upstream-relevant runtime fixes are in #17.
Activity
e-fu commentedon Aug 24, 2026
Status note: #17, which this issue references, is closed, as is the follow-up #19 — both branches are now well over a hundred commits behind and are not worth rebasing. The Go
js/wasmmodule that reproduced this has moved to a native Port helper on my side, so I no longer have a live reproducer.The gap itself is unchanged on
master: Go'swasm_exec.jsinit still readsglobalThis.process/path/fs.constants, and QuickBEAM's node surface doesn't supply them. Leaving this open rather than closing it, in case GoGOOS=jssupport is something you want to pick up — the property-access sequence in the issue body is still an accurate description of where it stops.