Patches the AssemblyScript compiler to utilize WASI imports instead of Web APIs.
Note that this shim also serves a higher purpose, that is as an example of how to target any non-standard interface with the AssemblyScript compiler, including your own!
See the assembly folder for the concrete implementations.
| Component | Functionality |
|---|---|
| console | assert, log, debug, info, warn, error, time, timeEnd |
| crypto | getRandomValues |
| date | now |
| internal | abort, trace, seed |
| performance | now |
| process | arch, platform, argv, env, exitCode, stdin¹, stdout¹, stderr¹, hrtime |
¹ Limited/basic support
First, install the WASI shim alongside the AssemblyScript compiler:
npm install --save-dev @assemblyscript/wasi-shim
Afterwards, reference the provided configuration file in your builds.
Option 1: Command line
When invoking asc manually, add --config ./node_modules/@assemblyscript/wasi-shim/asconfig.json as a command line option.
Option 2: Config file
When using an asconfig.json for your project, extend the provided configuration file instead:
{
"extends": "./node_modules/@assemblyscript/wasi-shim/asconfig.json",
// ...
}That's it. The AssemblyScript compiler now emits WASI-compatible modules. No more Web APIs!
Using this shim offers almost identical functionality to the former WASI support that was included with the AssemblyScript compiler up to version 0.20. The differences are:
- The prior
import "wasi"mechanism is no longer necessary and hence no longer supported. - The compiler does no longer try to detect if a module is a WASI command or reactor. By default, a command will be assumed. For a reactor, specify
--exportStart _initialize. See the WASI documentation for differences.
Since version 0.21, AssemblyScript considers WASI, derived proposals, the W3C's endorsement of its subgroup and the Bytecode Alliance's practices, that not all of their respective members necessarily are aware and/or approve of, harmful to open standards in general and the WebAssembly specification in particular.
The AssemblyScript project neither endorses nor officially supports any particular custom interface suitable to undermine purpose, goals and/or values of open Web standards. This package is nonetheless provided to our community for those who, given the subsequently established market situation, have no other choice than to use such interfaces or derived products. Regardless of the existence of this package, we explicitly welcome healthy competition in the rich design space of modern host interfaces. Specifically, we'd love to see (and use) a truly open host interface that keeps the Web in mind, i.e. adheres to WebAssembly's goals, while being portable, secure and efficient for many programming languages — including those that are a natural fit for the Web platform.