fix(builtins): compile bashkit for WASI targets + CI check for wasm32-wasip2

[chaliy]

What changed

The bashkit library now compiles for the WASI targets (wasm32-wasip1,
wasm32-wasip2) with the browser package's reduced feature surface
(scripted_tool,jq), and CI checks wasm32-wasip2 so it stays that way.

This opens bashkit to non-JS wasm runtimes (wasmtime, wasmer) and to the
wasmtime-in-a-micro-VM guest of
hyperlight-wasm. The
existing bashkit-wasm crate cannot serve those: it is wasm32-unknown-unknown

• wasm-bindgen JS glue.

Check-only for now — no WASI entry-point crate (WIT component) ships here. The
CI job exists so the library does not silently regress off the target before
that lands.

Why

Question came up whether bashkit can run inside Hyperlight. Raw Hyperlight
guests are no_std ELF binaries — not viable for a std-heavy interpreter. The
Hyperlight-Wasm route is, since its guest is wasmtime and bashkit already runs
single-threaded over an in-memory VFS. The only thing standing in the way was a
broken cfg.

Before / After

Before:

$ cargo check -p bashkit --target wasm32-wasip1 --features scripted_tool,jq
error[E0433]: failed to resolve: could not find `unix` in `os`
error[E0599]: no method named `as_bytes` found for reference `&std::ffi::OsStr`
error: could not compile `bashkit` (lib) due to 2 previous errors

$ cargo check -p bashkit --target wasm32-wasip2 --features scripted_tool,jq
error[E0658]: use of unstable library feature `wasip2`

format_support.rs imported std::os::unix::ffi::OsStrExt under
target_os = "wasi", where that module does not exist; the wasi equivalent is
unstable on wasm32-wasip2. Fixed by using stable as_encoded_bytes() on WASI.

After:

$ cargo check -p bashkit --target wasm32-wasip1 --features scripted_tool,jq
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.43s

$ RUSTFLAGS="-D warnings" cargo check -p bashkit --target wasm32-wasip2 --features scripted_tool,jq
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 23.22s

No observable behavior change on any currently supported target: the unix path
still uses OsStrExt::as_bytes, and the non-unix fallback is untouched.

Known gap, documented rather than fixed here: --features sqlite still fails on
WASI (tokio feature selection).

Risk

• Low
• Blast radius is one cfg in os_str_as_bytes. Unix behavior is byte-identical;
  only WASI, previously uncompilable, takes the new branch. The added CI step can
  only fail the build, never change artifacts.

Checklist

• Tests added or updated — the coverage for this is the wasm32-wasip2 CI
  check (a cfg-gated import cannot be exercised from host tests); host
  suite re-run green (cargo test -p bashkit --lib --features scripted_tool,jq:
  3076 passed), plus cargo fmt --all --check and
  cargo clippy -p bashkit --all-targets -- -D warnings
• Backward compatibility considered — internal code, no API change

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	8c7c382	Commit Preview URL Branch Preview URL	Aug 19 2026, 05:04 AM