Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

wasm32-wasi: callable exports (reactor/library mode), then a Component Model target

Chiusa
  • Qualcosa non va?
#522 1 commento 2 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
wasm
Ambito
compilers

Direzione di ricerca

Start by tracing how scriptc build --lib handles wasm32-wasi and where SC3002 rejects the library-mode profile, then compare that with the existing native library mode. The first milestone is a WASI Preview 1 reactor with declared exports, _initialize, and no _start; later milestones cover Component Model/WIT output and wasi:http.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Would you consider supporting a wasm32-wasi build whose exported functions a host can call, rather than only a _start command module?

Today scriptc build --lib is refused on wasm32-wasi with SC3002, and the compiler notes that the archive/reactor contract is not supported for WASI. What we're after, smallest first:

  1. Reactor exports on WASI Preview 1. Accept the existing library-mode profile on wasm32-wasi and emit its declared exports as wasm exports, with _initialize for setup and no _start. The async-free restriction that native library mode already has would be fine for a first version.
  2. Component Model output (WASI 0.2 / wasm32-wasip2). Take a WIT world and generate its typed imports and exports, so the output is a component that validates against that world. A documented stopgap would also help, for example reactor module + wasm-tools component new with the preview1 reactor adapter + hand-written WIT.
  3. Later, wasi:http outgoing requests on the component target, so fetch can work where the host grants it.

The use case is function-shaped: a host calls handle(input) -> output many times on one instance, rather than running main once. The static tier's small output and lack of an embedded engine make scriptc a very good fit for that, apart from this gap.

This looks related to #265: a WASI reactor would face the same async question, and a host-callable drain export would answer it for both.

Is this on the roadmap, or something you'd accept? We're happy to test preview builds under Wasmtime.

Lingua principale
TypeScript
Stelle
6.2k
Fork
183
Merge medio
2h 20m
PR unite (30g)
893

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di vercel-labs/scriptc

Tutte le issue di vercel-labs/scriptc

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.