WebAssembly spec: three stated components, six directories the README never mentions

The README is eighty-five words and half of them are triage

The front page of this repository does three things and stops. It says what the repository holds, which is the sources for the WebAssembly specification, a reference implementation and the official test suite. It links the formatted version of the specification, hosted separately. And it takes up the rest of its length on process: participation is welcome, but discussions about new features, significant semantic changes, or any specification change likely to generate substantial discussion should take place in the WebAssembly design repository first, so that this repository can remain focused. So the most prominent text in a repository that defines a language is a routing notice about where not to post. There is no feature list, no install instruction, no usage example and no explanation of what WebAssembly is. For that you have to go to the published specification the README links.

Six directories the front page does not mention

The README names three things: specification, implementation, test suite. The tree holds sixteen entries, and counting the directories that carry the specification and the implementation and the tests, six others sit beside them without appearing in the text. There are two directories for the specification itself, one named for the specification and one named for the document, so the sources and whatever produces the formatted output are kept apart. There is a directory named spectec, which the README does not mention at all and whose contents cannot be read from here. There is a proposals directory and a papers directory. And there is a file at the root named for the standards body that hosts the specification, a JSON file the README never refers to. A `.gitmodules` file is also present, which means part of what a clone needs comes from another repository, again unmentioned.

Feature discussion belongs in a different repository

The contribution model is the substance of the README, and it works by exclusion. The instruction covers three categories in turn: new features, significant semantic changes, and any specification change likely to generate substantial discussion. All three are to be taken to the design repository first, and the stated reason is that this repository should remain focused. Contributors are then pointed at a contributing guide in the repository. What makes that worth reading is the tension with the tree: there is a proposals directory here, so material of that kind has a home in this repository even though the process says the conversation happens elsewhere. The likely reading is that one is the archive and the other is the venue, but the README does not draw that line, so anyone with a proposal has to work out for themselves whether to open an issue here, open one in the design repository, or both.

Two workflows, no releases, and a test suite with no name in the process

The only badges on the front page are two, and they are not the usual version or build badges. They point at two continuous integration workflow files, one named for the spec and one named for the interpreter, which is a neat map of the repository's two halves. What the badges do not cover is the third component. The README calls the test suite official, but neither workflow is named for it, so whether the tests are run by the spec workflow, the interpreter workflow, or something else is not stated anywhere in the file. Alongside that, the repository has no GitHub releases at all, which is the correct shape for something versioned by specification phase rather than by tag, but it does mean there is no artefact to download and nothing to pin. The last commit on main is dated 2026-10-03.

An empty license field, a license file, and no license section

The repository's license field carries no value, while a LICENSE file sits at the root of the tree. The README has no license section, unlike most projects of this age, and never states the terms in prose. That is worth flagging rather than resolving: for a specification repository the licensing question is not a formality, because it determines who may copy the specification text into their own documentation, their compilers and their conformance suites. A reader who needs the answer cannot get it from the front page and cannot get it from the repository metadata, which leaves only the file itself. This is also the one thing the README does not delegate to another site, since the published specification is linked but the terms are not.

Citing and contributing are each one sentence

Two of the README's three sections are single instructions. The citing section, set in lowercase as the heading reads, says that for citing WebAssembly in LaTeX you should use a BibTeX file, which is in the repository. That is the whole of the citation guidance: one file, one format named, no note about version or date, and no guidance for citing anything other than LaTeX. The contributing section is likewise one sentence plus a link, pointing at the guidelines in a contributing document in the repository root. Both are reasonable delegations, since the files are there and both are short. They also mean that a first-time contributor arrives at the repository with two links to read and no map of how the three components fit together, which is a gap the tree fills and the README does not.

Editorial conclusion

This repository fits someone who needs to change or cite the specification text itself, or who wants the reference implementation and the official tests as a pair, since keeping those three in one tree is what makes a proposed change checkable against an implementation. Read it as a specification project rather than as a library, because there is nothing to install, no API to call and no release to pin. Two things to know before you start. Feature discussion is explicitly routed elsewhere, to the design repository, so a change that would generate real debate will not be well received here first. And the front page is not a description of the language: it holds no feature list, no usage and no explanation of WebAssembly itself, so anyone arriving to learn what WebAssembly is has to be sent to the published specification instead.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. WebAssembly/spec on GitHub