Skip to content

docs: correct stale references, document WASI 0.3.1, expand contribute page #63

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ericgregory merged 3 commits into from
Aug 26, 2026
Merged

docs: correct stale references, document WASI 0.3.1, expand contribute page #63

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9ad9d23
docs: correct stale references, document WASI 0.3.1, expand contribute
ericgregory Aug 26, 2026
c4fc793
docs: apply review corrections to the accuracy refresh
ericgregory Aug 26, 2026
d33f93b
docs: steer readers between WASI 0.2 and 0.3, and refresh 0.3 toolchains
ericgregory Aug 26, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 16 additions & 1 deletion docs/contribute.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,10 +2,25 @@
title: "Contribute"
sidebar_position: 6
---

## Contributing to this site

This site is a community effort supported by volunteers through the Bytecode Alliance's Special Interest Group for Documentation.
The **[Bytecode Alliance](https://bytecodealliance.org/)** is a community comprised of many individual contributors and 30+ companies involved in the WebAssembly space.

The Bytecode Alliance is focused on creating a shared implementation of standards produced by the WebAssembly CG, the WASI Subgroup, and other standardization bodies. We believe that standards are best informed by implementation. To enable this, we bring together a wide range of different use cases. Many of our contributors are also active in standardization and use this implementation experience and feedback to inform their work.

If you would like to get involved, you can find us on the SIG Documentation channel of the [Bytecode Alliance's Zulip server](https://bytecodealliance.zulipchat.com/) or [contribute on the WASI.dev GitHub repo](https://github.com/bytecodealliance/wasi.dev).
If you would like to get involved, you can find us on the SIG Documentation channel of the [Bytecode Alliance's Zulip server](https://bytecodealliance.zulipchat.com/) or [contribute on the WASI.dev GitHub repo](https://github.com/bytecodealliance/wasi.dev).

## Contributing to WASI

WASI itself is developed in the open by the **WASI Subgroup**, in [GitHub issues](https://github.com/WebAssembly/WASI/issues) and [pull requests](https://github.com/WebAssembly/WASI/pulls) on the WASI repository and in [Subgroup meetings](https://github.com/WebAssembly/meetings/tree/main/wasi) held every two weeks. Meetings are open to members of the W3C WebAssembly Community Group, which anyone can join.

Start with these documents:

* **[Contributing to WASI](https://github.com/WebAssembly/WASI/blob/main/CONTRIBUTING.md)** describes the phase process, what each phase requires, and how to propose a new API.
* **[The WASI Subgroup charter](https://github.com/WebAssembly/WASI/blob/main/docs/Charter.md)** defines what is in scope for WASI.
* **[Proposals](https://github.com/WebAssembly/WASI/blob/main/docs/Proposals.md)** lists every active proposal and its champions.
* **[`wasi-testsuite`](https://github.com/WebAssembly/wasi-testsuite)** takes contributions of new test cases and runtime adapters.

For an overview of how proposals advance and become part of a release, see the [Releases](./releases/index.md) page.
4 changes: 2 additions & 2 deletions docs/introduction.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,15 +12,15 @@ To date, WASI has seen three milestone releases: **0.1**, **0.2**, and **0.3**.

## Who are we?

WASI is an open standard under active development by the [**WASI Subgroup**](https://github.com/WebAssembly/WASI/blob/main/Charter.md) in the **W3C WebAssembly Community Group**. Discussions happen in [GitHub issues](https://github.com/WebAssembly/WASI/issues), [pull requests](https://github.com/WebAssembly/WASI/pulls), and [bi-weekly Zoom meetings](https://github.com/WebAssembly/meetings/tree/main/wasi).
WASI is an open standard under active development by the [**WASI Subgroup**](https://github.com/WebAssembly/WASI/blob/main/docs/Charter.md) in the **W3C WebAssembly Community Group**. Discussions happen in [GitHub issues](https://github.com/WebAssembly/WASI/issues), [pull requests](https://github.com/WebAssembly/WASI/pulls), and [bi-weekly Zoom meetings](https://github.com/WebAssembly/meetings/tree/main/wasi).

## Who are you?

WASI and Wasm are tools for any type of software developer: whether you're writing web apps, plugins, serverless functions, User-Defined Functions (UDFs) in a database, embedded controller components, sidecar networking filters, or something completely different. This site is intended to introduce the concepts and vocabulary of WASI regardless of your background, use-case, or familiarity with the WebAssembly ecosystem.

## How to get started

There are many different runtimes that support WASI including [Wasmtime](https://wasmtime.dev/), [WAMR](https://bytecodealliance.github.io/wamr.dev/), [WasmEdge](https://wasmedge.org/), [wazero](https://wazero.io/), [Wasmer](https://wasmer.io/), [wasmi](https://github.com/wasmi-labs/wasmi), [wasm3](https://github.com/wasm3/wasm3), [jco](https://github.com/bytecodealliance/jco), [pywasm](https://github.com/mohanson/pywasm) and [zwasm](https://github.com/zwasm/zwasm). Many of these runtimes have different areas of focus (i.e., IoT, embedded devices, and edge for WAMR, server-side and non-web embeddings with components for Wasmtime, and running in JS environments and browsers for Jco). The introductory documentation for each is a great place to start.
There are many different runtimes that support WASI including [Wasmtime](https://wasmtime.dev/), [WAMR](https://wamr.dev/), [WasmEdge](https://wasmedge.org/), [wazero](https://wazero.io/), [Wasmer](https://wasmer.io/), [wasmi](https://github.com/wasmi-labs/wasmi), [wasm3](https://github.com/wasm3/wasm3), [jco](https://github.com/bytecodealliance/jco), [pywasm](https://github.com/mohanson/pywasm) and [zwasm](https://github.com/zwasm/zwasm). Many of these runtimes have different areas of focus (i.e., IoT, embedded devices, and edge for WAMR, server-side and non-web embeddings with components for Wasmtime, and running in JS environments and browsers for Jco). The introductory documentation for each is a great place to start.

WASI can be implemented by both core Wasm modules and applications built according to the **Component Model**, a specification for Wasm applications that are interoperable and composable. You can learn more about components in the Bytecode Alliance's **[WebAssembly Component Model](https://component-model.bytecodealliance.org/)** documentation.

Expand Down
6 changes: 3 additions & 3 deletions docs/languages.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,21 +13,21 @@ The languages below can be compiled to WebAssembly with WASI support. Some toolc
| Go | Upstream Go (`GOOS=wasip1`) | Modules | 0.1 | Go Project | |
| Go | [`go-modules`](https://github.com/bytecodealliance/go-modules); [TinyGo](https://tinygo.org/) | Components | 0.2 | Bytecode Alliance; TinyGo Project | |
| Java | [GraalVM](https://www.graalvm.org/) | Planned | Planned | Oracle | Planned: see the [tracking issue](https://github.com/oracle/graal/issues/9762), [roadmap](https://github.com/orgs/oracle/projects/21/views/1), and [presentation](https://youtu.be/uefc2t9AmQI?t=1218) |
| JavaScript and TypeScript | [`jco`](https://github.com/bytecodealliance/jco) | Components | 0.2; 0.3 in progress | Bytecode Alliance | The `preview3-shim` package ships 0.3 host bindings; streams support landed, futures support following |
| JavaScript and TypeScript | [`jco`](https://github.com/bytecodealliance/jco) | Components | 0.2; 0.3 experimental | Bytecode Alliance | The [`preview3-shim`](https://www.npmjs.com/package/@bytecodealliance/preview3-shim) package provides experimental WASI 0.3 implementations for Node.js |
| Kotlin | [Kotlin](https://kotlinlang.org/docs/wasm-wasi.html) | Modules | 0.2 | JetBrains | Implementation in progress; see the [tracking issue](https://youtrack.jetbrains.com/issue/KT-64568) |
| MoonBit | MoonBit compiler with [`wit-bindgen` MoonBit backend](https://github.com/bytecodealliance/wit-bindgen/tree/main/crates/moonbit) | Modules; components via `wasm-tools component new` | 0.2 | MoonBit | |
| Python | [`componentize-py`](https://github.com/bytecodealliance/componentize-py) | Components | 0.2 | Bytecode Alliance | |
| Python | [`cpython`](https://snarky.ca/state-of-wasi-support-for-cpython-march-2024/) | Modules | 0.2 | Python | Implementation in progress |
| Ruby | [`ruby.wasm`](https://github.com/ruby/ruby.wasm) | Modules | 0.2 | Ruby | Implementation in progress |
| Rust | [`wasm32-wasip2`](https://doc.rust-lang.org/rustc/platform-support/wasm32-wasip2.html) and [`wasm32-wasip3`](https://doc.rust-lang.org/nightly/rustc/platform-support/wasm32-wasip3.html) compiler targets | Modules and components | 0.1, 0.2; 0.3 nightly | Rust Project | `wasm32-wasip2` is Tier 2 on stable; `wasm32-wasip3` is Tier 3, nightly only. See the [0.2 introduction](https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets/) and [0.2 stabilization](https://blog.rust-lang.org/2024/11/26/wasip2-tier-2/) |
| Rust | [`wasm32-wasip2`](https://doc.rust-lang.org/rustc/platform-support/wasm32-wasip2.html) and [`wasm32-wasip3`](https://doc.rust-lang.org/nightly/rustc/platform-support/wasm32-wasip3.html) compiler targets | Modules and components | 0.1, 0.2, 0.3 | Rust Project | `wasm32-wasip2` is Tier 2 on stable; `wasm32-wasip3` is Tier 3, nightly only. The [`wasip3`](https://crates.io/crates/wasip3) crate provides WASI 0.3 bindings and works from either component target. See the [0.2 introduction](https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets/) and [0.2 stabilization](https://blog.rust-lang.org/2024/11/26/wasip2-tier-2/) |
| Swift | [Swift](https://www.swift.org/) | Planned | Planned | Swift | Planned: see the [accepted roadmap vision](https://forums.swift.org/t/accepted-vision-a-vision-for-webassembly-support-in-swift/80332) |
| Zig | `zig build-exe -target wasm32-wasi` | Modules | 0.1 | Zig | No first-party Zig component toolchain |

### Notes

- **Modules vs components.** A Wasm **module** is a single binary in the core WebAssembly format and can use WASI 0.1. A **component** is built to the Component Model and can use WASI 0.2 or 0.3, gaining composability, cross-language interoperability, and richer interface types. See the [Releases](releases/index.md) and [Roadmap](roadmap.md) pages for more on the WASI releases.
- **Adapting modules to components.** Several toolchains produce core modules today and wrap them into components using [`wasm-tools component new`](https://github.com/bytecodealliance/wasm-tools) with a 0.1-to-0.2 adapter. This is the path for C/C++ and MoonBit.
- **WASI 0.3 ecosystem state.** Broad language-level 0.3 support is still landing. The Rust `wasm32-wasip3` target is Tier 3 (nightly only). `jco` ships a `preview3-shim` package with streams support landed and futures support following. Other toolchains have not yet shipped 0.3 support.
- **WASI 0.3 ecosystem state.** Broad language-level 0.3 support is still landing. Rust has WASI 0.3 bindings in the [`wasip3`](https://crates.io/crates/wasip3) crate, usable from the stable Tier 2 `wasm32-wasip2` target or the nightly Tier 3 `wasm32-wasip3` target. `jco` ships an experimental `preview3-shim` for Node.js. Other toolchains have not yet shipped 0.3 support, so target WASI 0.2 with those. A WASI 0.3 runtime also runs WASI 0.2 components.
- **Version pinning.** The Component Model defines [canonical interface names](https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#-canonical-interface-name) so that components can link across compatible versions, but not all tools support this version-aware linking yet. Until they do, target the same version (`0.3.0`) across all WIT-aware tools. Mismatches surface as confusing `wrong type` errors at instantiation.

### Building guides
Expand Down
Loading
Loading