Wasmnizer-ts utilizes WasmGC to compile TypeScript source code into WebAssembly bytecode, and support dynamic type (such as any) through host APIs. The Wasmnizer-ts now supports a strict subset of TypeScript and continuously strives to accommodate more semantics.
There are three components in Wasmnizer-ts:
ts2wasm-compiler: a compiler for compiling TypeScript source code into WasmGC bytecode.ts2wasm-stdlib: standard library implemented in ts source code, will be compiled with application together. See standard library.ts2wasm-runtime-library: runtime libraries for exposing host APIs required for running the generated wasm module, including:libdyntype: support dynamic objects, see API spec here. We have proposed a WASI proposal.libstruct-indirect: access WasmGC struct fields through index calculated during runtime, see API spec here. These APIs are used to emulate the behaviour of the proposed struct.get/set_indirect opcode.libstd: standard library implemented in native, such asconsole.log, see standard library.
Note: This project is highly experimental and under active development, DO NOT use in production
- garbage collection.
ts2wasm-compilerleverage WebAssembly GC proposal, which can benefit from runtime's GC capability. - optimization.
ts2wasm-compileruses binaryen as backend, which can benefit from binaryen's powerful optimization capabilities. - small footprint. Data structures in source code is represented as WasmGC types, which avoids the requirement for
memory allocatorandgarbage collectorinside wasm module. - static compilation. Type information in TypeScript source code is used to create static WasmGC types, which avoids the overhead of dynamic type checking.
- dynamic typing.
anyand other dynamic types in TypeScript source code are supported by host APIs.
The wasm module generated by ts2wasm-compiler is designed to be executed in a WasmGC runtime environment. The runtime should provide the following capabilities:
- WebAssembly proposals:
- WasmGC (mandatory): WasmGC proposal, which is a garbage collection mechanism for WebAssembly.
Note: the GC opcode generated by binaryen is slightly different than GC MVP, please see here for details.
- Exception handling (required by try-catch statements): exception handling proposal, which adds exception handling mechanism to WebAssembly.
- stringref (required by stringref feature): reference-typed strings proposal, provide a language independent string representation.
- WasmGC (mandatory): WasmGC proposal, which is a garbage collection mechanism for WebAssembly.
- APIs:
- libdyntype API (required by dynamic typing): APIs for supporting dynamic objects.
- libstruct-indirect API (required by
interfacetype): APIs for accessing WasmGC struct fields through index calculated during runtime. - libstd API (required by standard libraries): APIs for providing standard libraries from host environment.
Wasmnizer-ts currently implemented host APIs on multiple environments:
- WebAssembly Micro Runtime (WAMR):
libdyntype API,libstruct-indirect APIandlibstd API - chrome browser and nodejs (20.6.1+): part of
libdyntype APIimplemented with JavaScript
Please see feature list for supporting status of each feature.
Please goto Getting Started for how to use the project and Introduction for more details.
This will compile our samples and check if the compiler exit normally, it doesn't guarantee the correctness of the generated wasm module.
npm run testSee validate/wamr for how to validate results on WAMR
Code is required to be formatted with npm run lint.
Changes to Wasmnizer-ts are managed through github pull requests (PR).
Wasmnizer-ts uses the same license as LLVM: the Apache 2.0 license with the LLVM exception. See the LICENSE file for details. Any contributions you make will be under the same license.