feat: Lightweight WASI Implementation for Reactor Pattern

[swarna1101]

Summary

Introduces a minimal WASI Preview 1 implementation optimized for reactor-style usage with low resource overhead and fast instantiation.

Problem Solved

• Addresses issues with heavy wasmer-wasix implementation (high memory usage, slow instantiation, "too many files open" errors)
• Provides lightweight alternative for scenarios requiring many fast instance creations
• Designed specifically for reactor pattern (multiple entrypoints, function calls)

Key Features

• Minimal WASI Preview 1 support: args_get, environ_get, clock_time_get, random_get, proc_exit, sched_yield
• Lightweight: No filesystem, networking, or threading initialization
• Reactor-friendly: Optional memory for reactor pattern, configurable args/envs/clock/random
• Deterministic: Configurable random seeds and clock offsets

Usage

use wasmer_wasi_light::{WasiLightEnv, generate_import_object};

let wasi_env = WasiLightEnv::new()
    .args(vec!["arg1".to_string()])
    .envs(HashMap::from([("KEY1".to_string(), "VALUE1".to_string())]))
    .clock_offset(Duration::from_secs(3600))
    .random_seed(42);

let import_object = generate_import_object(&mut store, &wasi_env)?;
let instance = Instance::new(&mut store, &module, &import_object)?;

[promptless]

📝 Documentation updates detected!

New suggestion: Add documentation for wasmer-wasi-light lightweight WASI implementation

[Arshia001]

Hey @swarna1101, thanks for this contribution!

While I generally like the idea of having light-weight solutions, there are a few issues I can see with this code:

• Some WASI syscalls are not implemented "properly", in that they simply return an error code
• Some WASI syscalls are not implemented at all; this breaks loading modules that need those syscalls
• The code is highly opinionated and not really appropriate as a general-purpose solution.

I wonder if it'd make more sense to put this somewhere else, since it doesn't look like it depends in any way on existing within the main Wasmer repo?

[swarna1101]

While I generally like the idea of having light-weight solutions, there are a few issues I can see with this code:

• Some WASI syscalls are not implemented "properly", in that they simply return an error code
• Some WASI syscalls are not implemented at all; this breaks loading modules that need those syscalls
• The code is highly opinionated and not really appropriate as a general-purpose solution.

I wonder if it'd make more sense to put this somewhere else, since it doesn't look like it depends in any way on existing within the main Wasmer repo?

Thank you for the thorough review. You're absolutely right that the current implementation has limitations - some syscalls return error codes rather than proper implementations, and missing syscalls could break module loading.

This wasmer-wasi-light crate was intended as a minimal, opinionated implementation for specific use cases where full WASI compliance isn't needed. It's not meant to be a general-purpose WASI solution, but rather a lightweight alternative for scenarios where you only need basic functionality.

You raise a good point about the repository placement. Since this crate doesn't depend on the main Wasmer repo internals and is more of a standalone utility, it could indeed live in a separate repository or as a separate project. This would also make it easier to maintain and version independently.

Would you prefer if I either (a) move this to a separate repository as a standalone wasmer-wasi-light project, or (b) remove it from the main Wasmer repo entirely? This would help keep the main Wasmer codebase focused on the core, fully-compliant WASI implementation.

If you'd prefer to keep it in the Wasmer ecosystem, I could refactor it to be more clearly marked as experimental/opinionated and add better documentation about its limitations and intended use cases.

[Arshia001]

I believe this code can live in a repo within your own organization. Closing the PR.