Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Missing ability to access built older versions of the WebAssembly specification in archivable form

Open
  • Is something wrong?
#1,736 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Documentation
Clarity
Needs clarification
Activity status
Stale
Tech stack
wasm
Domain
documentation

Research direction

No repository files or tests are named. Start by reviewing how the current WebAssembly specification builds and publishes its downloadable artifacts, then compare the W3C core 1.0 page with the proposal mirror linked in the issue. Done means an authoritative, archivable set of built WebAssembly 1.0 artifacts is available.

Written by the indexing model from the issue text.

Description

There does not appear to be a simple way to access built older versions of the WebAssembly specification, particularly 1.0, in archivable form (the various builds, i.e. PDF etc.)

I was at least able to find the W3C version of the core specification ( https://www.w3.org/TR/wasm-core-1/# ), but that appears to be all, and it doesn't appear to have any standardized archival download readily available.

Why care about 1.0?

There are two main use-cases I can think of for the WebAssembly 1.0 specification:

  • With the addition of extensions/etc. onto the "MVP" version of WebAssembly in the core specification (for example: v128), the support for these in browsers that are actually available on end-user devices will vary. There will be, for quite some time, the need to maintain WebAssembly 1.0-compliant versions of ecosystem software.
  • Non-browser targets (i.e. WASI) may use custom WebAssembly runtimes that may not have use for functionality such as vectorization. Alternatively, non-browser usecases may require targetting outdated runtimes. These usecases benefit from being able to point at a specific specification version as the standard.
    • A practical example would be https://github.com/dtolnay/watt, which contains a WebAssembly interpreter. This interpreter seems to be intended solely for the purpose of running compiled Rust code handling abstract token streams. This is reliant on upstream tooling supporting an unextended WebAssembly 1.0 environment -- it would break if tooling support for WebAssembly 1.0 were to begin failing (i.e. by including WebAssembly 2.0 features in code intended to target WebAssembly 1.0).

It is thus important to keep available the specification versions that actually apply to these targets.

Workaround

A present workaround is to use the mirrors generated by WebAssembly project proposals that were forked from late-stage 1.0, i.e. https://webassembly.github.io/multi-value/core/_download/WebAssembly.pdf -- however, there are still some differences, so this is probably not a definitive 1.0.

Dominant language
WebAssembly
Stars
3.5k
Forks
539
Avg merge
10h 38m
Merged PRs (30d)
12

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from WebAssembly/spec

All issues in WebAssembly/spec

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.