GeezerVison

Overview

With --wasi-runtime uwasi, the generated platform wrappers import useAll and MemoryFileSystem, so every bundle ships UWASI's in-memory file system. That makes it larger than the @bjorn3/browser_wasi_shim default, and most apps never open a file.

Bundled with esbuild (minified, gzip):

1. Default feature set

The wrappers now import useStdio, useArgs, useEnviron, useClock, usePoll, useProc and useRandom. A Swift executable needs args, environ, random, clock and proc to start, and wasi-libc needs fd_prestat_get to return EBADF while it scans for preopens. Stdio also keeps runtime errors such as Fatal error: Index out of range visible. File syscalls now return ENOSYS.

2. Code coverage

With --enable-code-coverage, the Node wrapper adds useMemoryFS, because the test runner reads the coverage profile through extractFile. The browser wrapper never imports a file system, and nothing imports useAll.

3. Custom setups

An app that needs a file system or a different feature set can pass its own wasi object to the generated instantiate.js. The README and the package output docs describe this. If that turns out to be too much work for users, we can add a config flag later.

Test Plan

• swift test --package-path ./Plugins/PackageToJS
• node --test Plugins/PackageToJS/Tests/Inputs/UWASIAdapterTests.mjs
• Examples/NodeJS with --wasi-runtime uwasi: node main.mjs prints the greeting, and the generated wrappers import no file system
• A Swift executable that calls print and fopen: output works, and fopen fails without the file system