Reading auto-generated WIT (<pkg>.wit.md)

mty build --target wasm32-* emits a Component Model component whose contract is described by a generated WIT document. The full text is available on the build artifact (WasmArtifact::wit_text) and embedded as a component-type custom section in the .wasm.

This page explains how to read that document.

Header

// AUTO-GENERATED by mty-codegen-wasm.
// Source target: wasm32-wasi — Component Model output.
package mighty:<pkg-name>;

• The leading comments come from the build process; do not edit the document by hand — the next build will overwrite it.
• The package id is always mighty:<pkg-name>, where <pkg-name> is the source-file stem, normalized to kebab-case.

World

Every package emits exactly one world named <pkg-name>-world:

world <pkg-name>-world {
  import wasi:cli/log;          // or mighty:web/log for wasm32-web
  import mighty:caps/fs;       // one per cap family used in the package
  import mighty:caps/net;
  // ... record / enum / variant declarations ...
  export main: func();
  export greet: func(name: string) -> string;
  // effects: Net, Time         // informational, not part of the contract
}

• Imports = capabilities the package needs from the host.
• Exports = functions callable from the host.
• Type declarations (record, enum, variant) live inside the world; they're referenced by export signatures.
• // effects: comment lists the Mighty effects the package declares. WIT has no first-class effect concept, so this is informational only — useful for mty pkg verify or audit tooling.

Type mappings

WIT type	Mighty origin
s8 .. s64, u8 .. u64	i8–i64, u8–u64, default int
f32, f64	f32, f64, default float
bool, char, string	bool, char, str / String
list<u8>	Bytes
list<T>	[T] / Array<T>
tuple<T1, T2, ...>	(T1, T2, ...)
record name { f: T }	struct name { f: T }
enum name { a, b }	enum name { A, B } (no payloads)
variant name { a(T), b }	enum name { A(T), B } (with payloads)
option<T>	T?
result<T, E>	Result<T, E>

Types Mighty can't yet round-trip through WIT (raw pointers, captures, generic params) are silently dropped from the public surface; the function or type carrying them is omitted.

Host stub packages

The bottom of every emitted document declares stub packages so wit_parser can resolve the world's imports without external dependencies:

package mighty:caps { ... }
package wasi:cli { ... }      // for wasm32-wasi
package mighty:web { ... }   // for wasm32-web

These are not the canonical upstream definitions — they're the minimum surface the v0.2 backend imports. When deploying against a real WASI host, the host's own WIT packages take precedence at component-link time.

Editing your component shape

You can't edit the emitted WIT directly. The shape comes from your Mighty source. To change it:

• Add an export — declare a new top-level fn. Names starting with _ are private and won't be exported.
• Add a capability import — accept a Cap<family> parameter in any exported fn. The cap family appears as an import in every WIT regen.
• Add a type — declare a struct or enum. Public ADTs (no _ prefix) appear as record / enum / variant.

User-authored WIT (overlaying or replacing the generated surface) is planned for v0.3; track A47-followups and WASM_CM_V0_2_NOTES.md.