# WebAssembly Component Model: design, specifications, and tests

> WebAssembly/component-model is the standardization repository for the Component Model, its WIT interfaces, text and binary formats, linking model, concurrency design, ABI, and WAST tests. It is a specification project rather than an installable runtime, and parts of the design remain incremental.

**WebAssembly/component-model** — Repository for design and specification of the Component Model

- Repository: https://github.com/WebAssembly/component-model
- Stars: 1,387 · Forks: 132
- Language: WebAssembly
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/webassembly-component-model

## A standardization workspace for WebAssembly components

WebAssembly/component-model addresses a specific layer of the WebAssembly ecosystem: how separately compiled components expose typed interfaces, connect through a shared linking model, and exchange values according to a defined ABI. It is intended for people designing or implementing component-aware compilers, runtimes, producer tools, consumer tools, interface definitions, and conformance tests. The repository is not itself a compiler, runtime, package manager, or application framework.

Its scope is broader than a prose design proposal. The README places the repository within the W3C WebAssembly Community Group and divides its contents into high-level material, low-level specifications, and a growing WAST test suite. The high-level documents cover goals, use cases, design choices, and frequently asked questions. The low-level material includes WIT, the component text format, binary format, linking, concurrency, and the Canonical ABI.

This makes the repository most useful to infrastructure authors who need to reason about agreement between separate tools. It also gives component users a place to inspect the assumptions behind interfaces and linking. The trade-off is that this is a moving standardization workspace, not a finished package with one installation path. The README explicitly says that a formal specification and reference interpreter will be added in the future.

## WIT interfaces and the component linking model

WIT is the repository's interface definition language for component contracts. The repository lists WIT separately from the component text and binary formats, which indicates that interface source, textual component representation, and encoded component representation are distinct concerns. An implementation team may therefore need to reason about more than one representation when it builds support for components.

The linking material defines how components are connected. WASI Developer Preview 0.2.0 includes both shared-nothing and shared-everything linking, along with a variety of high-level value types, resource types represented by handles, and WIT. Shared-nothing and shared-everything are materially different connection models: one does not rely on shared component memory, while the other permits components to share memory. The repository documentation is therefore relevant to both component isolation requirements and designs that need direct memory sharing.

Resource handles are another interface boundary that implementers must account for. A WIT contract can describe resource types, but correctly connecting such types still depends on the linking rules and ABI. This repository should be consulted alongside an implementation's chosen runtime because it describes the model, not the behavior of a named runtime.

## Canonical ABI, binary format, and conformance tests

The CanonicalABI.md document is the repository's description of the ABI that connects the component model to its implementation. It matters because two tools can agree on WIT while still differing in how they lower component values, manage resources, lift values, or invoke exported operations. The ABI document narrows that area, but an implementation still needs to follow the relevant version rather than infer behavior from repository directory names.

The binary format is specified separately in design/mvp/Binary.md, while design/mvp/Explainer.md covers the text format. The top-level spec directory exists, but the README says that a formal spec and reference interpreter will be added in the future. As a result, repository layout alone should not be treated as evidence that every document has the same maturity or implementation status.

The test directory contains a growing WAST test suite. WAST gives implementations a shared body of syntax-oriented conformance cases, although the README does not claim that the suite replaces all runtime integration testing. The absence of GitHub releases also means there is no release artifact to select from the repository's release page. Implementers should identify the exact document set and tool compatibility they intend to support before relying on behavior.

## Incremental concurrency in WASI Developer Preview

The concurrency design is explicitly tied to WASI Developer Preview milestones. Version 0.3.0 is described as the first release with native concurrency support in the Component Model and WIT. It adds asynchronous functions, streams, futures, and new Canonical ABI built-in functions. Version 0.3.1 adds the map<K,V> type and the implements and external-id annotations.

These additions change both the interface language and the runtime contract. Supporting async alone is not sufficient if a tool also needs to produce or consume streams and futures or implement the associated ABI built-ins. The map<K,V> addition and interface annotations likewise need to be considered by parsers, validators, generators, and producers or consumers that preserve that information.

Concurrency remains part of an incremental design. The README identifies cooperative threads as an emoji-gated feature intended for a subsequent WASI Developer Preview release, so the current repository should not be read as evidence that every planned concurrency feature is already enabled. The producer and consumer tools mentioned by the README are responsible for keeping enabled features stable within a Developer Preview release, which makes tool compatibility a concrete adoption concern.

## Reading the repository without assuming a finished runtime

There are no installation instructions in the README because the repository is not presented as a distributable runtime. It says that the Component Model is being standardized and points readers who want a more user-focused explanation to the Component Model Documentation at component-model.bytecodealliance.org. For engineers looking for a ready-made implementation, that user documentation is the stated place to start rather than installing this repository as a package.

There is likewise no first-run command to give. The repository contains specifications and tests, not an application initialization flow. A concrete first use for an implementer would be to consult the design documents relevant to an interface, then compare that behavior against the WAST suite and the producer and consumer tools targeted by the relevant WASI Developer Preview release. No particular command for running the suite is documented in the README.

The repository has no GitHub releases. Version labels such as 0.2.0, 0.3.0, and 0.3.1 refer to WASI Developer Preview releases as described by the README, not GitHub releases of WebAssembly/component-model. Confusing these version sources would make upgrade planning harder.

## License scope and maintenance implications

The repository is licensed under a custom licence that GitHub cannot classify, and the README directs readers to the LICENSE file. The repository also contains LICENSE-APACHE, but the README does not explain how that file relates to the custom terms. Users who need exact permissions, conditions, or compatibility terms must inspect LICENSE and determine how LICENSE-APACHE applies; the repository metadata alone is not enough for a legal conclusion.

The repository is not archived, and its last push was on 2026-10-15. That date indicates recent work at that point, but it does not prove that every document or proposed feature is production-ready. The README's milestone language is the more important adoption constraint: the Component Model is still being developed incrementally, and formal specification and reference interpreter work is described as future additions.

There are no GitHub releases from which to infer upgrade artifacts or release notes. Consumers therefore face specification and tool-compatibility costs rather than a conventional package upgrade path. Producer and consumer tools must support the enabled feature set they share, while implementers need to track changes across WIT, linking, the Canonical ABI, text and binary formats, concurrency, and the test suite.

## Why a conventional WebAssembly runtime is not a substitute

The closest practical alternative is to rely on a runtime or toolchain's own component support rather than implementing against WebAssembly/component-model directly. The difference in approach is that this repository defines and tests the shared contract, while a runtime generally provides executable behavior. An application developer who only needs an existing toolchain to consume components may need the runtime's documented integration path more than the repository's low-level design documents.

An implementation author faces a different task. A runtime that exposes WebAssembly modules does not, from the evidence here, imply support for WIT interfaces, component text or binary formats, resource handles, shared-everything linking, streams, futures, or the Canonical ABI. Those are separate requirements identified by this repository. Choosing the conventional route can reduce immediate implementation work, but it does not establish that all component-model features are available or compatible with the intended producer.

The practical boundary is therefore between using an existing implementation and implementing the model. This repository is the stronger reference for the latter, while the user-focused Component Model Documentation is the stated starting point for the former.

## Conclusion

Engineers implementing WebAssembly component tooling should use this repository when they need the evolving design, interface documents, and test suite. Developers seeking an installable package, runtime, or immediately stable specification should first confirm whether the WASI Developer Preview features they need are stable across their producer and consumer tools, and whether the repository's custom LICENSE permits their intended use.

## FAQ

### Is WebAssembly/component-model an installable runtime?

No. The README describes it as a repository for the design and specification of the Component Model, containing documents and a WAST test suite rather than a runtime package or installation command.

### Where should I start when implementing WebAssembly Component Model support?

Begin with the documents relevant to the feature being implemented, such as WIT, Linking, Binary, Concurrency, or CanonicalABI. The repository also contains design goals, use cases, design choices, a FAQ, and tests, but it does not document one universal setup command.

### Does WebAssembly/component-model provide a formal specification and reference interpreter?

Not yet, according to the README. It states that the repository will additionally contain a formal specification and a reference interpreter in the future.

## Sources

- [Issues](https://github.com/WebAssembly/component-model/issues)
- [README](https://github.com/WebAssembly/component-model/blob/main/README.md)
- [WebAssembly/component-model on GitHub](https://github.com/WebAssembly/component-model)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/webassembly-component-model