Tracks finishing Windows-host support for the @columnar-tech/dbc-wasm package (introduced in #395). Linux and macOS are validated in CI; Windows is experimental and dropped from the WASM CI matrix until the issue below is resolved.
Fixed on the way (already on the branch / in #395)
- Env-size overflow:
boot.cjs no longer forwards the full process.env into the wasm runtime. A GitHub Actions Windows env is large enough to overflow wasm_exec.js's combined argv+env size cap, making go.run() throw before startup. Now only the vars GOOS=js needs are forwarded (HOME/XDG_*/TMPDIR), via curateGoEnv().
- Temp dir:
GOOS=js os.TempDir() reads only $TMPDIR (else /tmp, missing on Windows). curateGoEnv() maps TMPDIR from %TMPDIR%||%TEMP%||%TMP% and normalizes backslashes.
With those, the Windows runtime boots and install() completes.
Remaining blocker
listInstalled() returns [] on Windows even though install() wrote the manifest. Repro (from the WASM windows-latest smoke):
installDir contains test-driver-1.toml at the top level (confirmed via Node fs.readdirSync).
dbc.listInstalled(installDir) → config.FindDriverConfigsIn(\"C:/.../installDir\") → loadDir → returns no drivers.
Switching loadDir from fs.Glob(os.DirFS(dir), \"*.toml\") to os.ReadDir(dir) did not help (identical empty result), so it's not the os.DirFS abstraction. Leading hypothesis: under GOOS=js, a normalized drive-letter path like C:/Users/... is not treated as absolute (filepath.IsAbs is false on the unix-like js target), so the runtime's path resolution for discovery diverges from where install actually wrote. Needs Go-side, syscall-level diagnostics on a real Windows runner (os.Stat/ReadDir/Open results + the exact resolved path inside loadDir).
Action
Tracks finishing Windows-host support for the
@columnar-tech/dbc-wasmpackage (introduced in #395). Linux and macOS are validated in CI; Windows is experimental and dropped from the WASM CI matrix until the issue below is resolved.Fixed on the way (already on the branch / in #395)
boot.cjsno longer forwards the fullprocess.envinto the wasm runtime. A GitHub Actions Windows env is large enough to overflowwasm_exec.js's combined argv+env size cap, makinggo.run()throw before startup. Now only the varsGOOS=jsneeds are forwarded (HOME/XDG_*/TMPDIR), viacurateGoEnv().GOOS=jsos.TempDir()reads only$TMPDIR(else/tmp, missing on Windows).curateGoEnv()mapsTMPDIRfrom%TMPDIR%||%TEMP%||%TMP%and normalizes backslashes.With those, the Windows runtime boots and
install()completes.Remaining blocker
listInstalled()returns[]on Windows even thoughinstall()wrote the manifest. Repro (from the WASM windows-latest smoke):installDircontainstest-driver-1.tomlat the top level (confirmed via Nodefs.readdirSync).dbc.listInstalled(installDir)→config.FindDriverConfigsIn(\"C:/.../installDir\")→loadDir→ returns no drivers.Switching
loadDirfromfs.Glob(os.DirFS(dir), \"*.toml\")toos.ReadDir(dir)did not help (identical empty result), so it's not theos.DirFSabstraction. Leading hypothesis: underGOOS=js, a normalized drive-letter path likeC:/Users/...is not treated as absolute (filepath.IsAbsis false on the unix-like js target), so the runtime's path resolution for discovery diverges from whereinstallactually wrote. Needs Go-side, syscall-level diagnostics on a real Windows runner (os.Stat/ReadDir/Open results + the exact resolved path insideloadDir).Action
windows-latestto.github/workflows/wasm.ymlonce discovery works.GOOS=js+ Windows drive-path resolution behavior inconfigdriver discovery.