v2.23.2 - apollovm_wasm 1.1.0: wasm_run 0.2, no install step

apollovm_wasm 1.1.0 — wasm_run ^0.2.0+1

wasm_run 0.2.0 is a breaking release. It is absorbed inside apollovm_wasm, so consumers keep the same WasmRuntimeIO API and gain one thing: there is no install step any more.

dart run wasm_run:setup is gone. The SDK's build hooks download the native library into .dart_tool/lib/ during dart run / dart test / dart compile, so that directory is now searched first — walking up to every enclosing package root, so a nested package finds a library fetched by its workspace — along with .dart_tool/wasm_run/ (the wasm_run:build_binaries output).

Three further breaks needed handling:

• The bindings moved to flutter_rust_bridge 2.x, so the symbol that identifies a genuine wasm_run library changed: wire_compile_wasm → frb_get_rust_content_hash. Validating the old one rejected every 0.2 library.
• WasmRunLibrary.isReachable() became Future<bool>.
• wasm_run 0.2 initializes its Rust bindings asynchronously, and no longer locates its own library in a pure-Dart application. WasmRunLibrary.setUp() is now awaited once, lazily, on the first module compile — ensureBooted() and isSupported stay synchronous, as WasmRuntime requires, and only probe for the library.

WASM_RUN_DART_DYNAMIC_LIBRARY (the variable wasm_run itself reads) now overrides the library path. The older WASM_RUN_LIB_PATH is still honored, and is finally read as a path: it used to be consulted only on platforms with no known library name, and then joined with candidate directories as if it were a file name.

apollovm_wasm now requires Dart >= 3.10, matching wasm_run 0.2.

apollovm 2.23.2

Nothing changes for package:apollovm itself — it still compiles Wasm everywhere and pulls in no native toolchain. This release only corrects the places that told people to run a command that no longer exists: mcp doctor, the Wasm test suite and WASM_BACKEND_PLAN.md. CI drops its three wasm_run:setup steps.

Known issue: macOS on Apple Silicon

The upstream aarch64-apple-darwin 0.2.0 binary is killed by macOS (SIGKILL, Code Signature Invalid) the moment wasmtime executes JIT-compiled Wasm inside the JIT Dart VM — i.e. under dart run and dart test. Compiling and instantiating modules is fine; only the call into generated code trips it, and wasm_run 0.1.0+2 does not hit it on the same machine.

Ahead-of-time compilation is unaffected, so on macOS arm64 run Wasm through dart test --compiler exe / dart compile exe. It is a macOS code-signing enforcement, so other platforms are not expected to be affected — Linux is verified in CI (2541 tests, JIT and AOT).

Full Changelog: v2.23.1...v2.23.2