You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Pure-Go bindings via wasm32-wasip1 + wazero (CGO_ENABLED=0) #71
I've published Go bindings that take a different approach from #30, and
wanted to check whether you'd want them linked from the README, upstreamed,
or simply left downstream.
#30 binds the crate through cgo with prebuilt per-platform archives. This one
compiles the crate to a wasm32-wasip1 command module, embeds it with go:embed, and runs it under wazero. The trade-offs are genuinely different,
so I don't think it displaces #30:
CGO_ENABLED=0, cross-compiles wherever Go does — verified on
linux/{amd64,arm64,riscv64,ppc64le,386,s390x}, darwin, windows, freebsd
one 4.83 MB wasm artifact instead of a per-platform archive matrix
self-contained single binary, no external process, no system deps
the cost: interpreted execution. A 1 KB docx converts in 5 ms, but one with
a 5 MB uncompressed body takes 16.9 s against 1.1 s compiled. There's an
opt-in WithCompiler() for callers who can afford ~2 s and 576 MB at
startup.
One thing worth noting given #67: because the crate runs as a sandboxed wasm
guest, the lopdf SIGABRT path surfaces as a returned error rather than
killing the host process — wazero bounds guest call depth and a wasm guest
can't signal the host. A cgo binding has no such containment.
The exit-code table between my WASI shim and the Go error types is pinned to ConvertError::code(), so I'd like to know how stable you consider that and to_markdown_bytes to be across releases. The crate is pinned with = and
rebuilds go through a reviewed PR, but I'd rather track your intent than guess.
Happy to move any of this into the repo if a go/ directory using the wasm
path is something you'd want.
Go bindings are something we may do in tree later, so I would rather leave this downstream for now than link or upstream it. to_markdown_bytes and ConvertError::code() are stable at the moment, but the crate is pre-1.0 and still moving, so do not treat either as frozen.
Go bindings are something we may do in tree later, so I would rather leave this downstream for now than link or upstream it. to_markdown_bytes and ConvertError::code() are stable at the moment, but the crate is pre-1.0 and still moving, so do not treat either as frozen.
Understood, downstream it is. Thanks for the ABI answer — that is the part I
needed. The bindings pin the crate with =, map unknown code() values onto
a generic wasm-failure error instead of panicking, and report the embedded
crate version at runtime, so a pre-1.0 crate that moves degrades rather than
breaks. I will keep tracking releases manually.
Activity
tomsideguide commentedon Aug 10, 2026
Go bindings are something we may do in tree later, so I would rather leave this downstream for now than link or upstream it.
to_markdown_bytesandConvertError::code()are stable at the moment, but the crate is pre-1.0 and still moving, so do not treat either as frozen.xusenlin commentedon Aug 10, 2026
Understood, downstream it is. Thanks for the ABI answer — that is the part I
needed. The bindings pin the crate with
=, map unknowncode()values ontoa generic wasm-failure error instead of panicking, and report the embedded
crate version at runtime, so a pre-1.0 crate that moves degrades rather than
breaks. I will keep tracking releases manually.