Use with wasi-shim?

I see you’ve updated to use wasi-shim, but it’s not clear how usage/configuration has changed.

• No more need to import "wasi", right?
• How do I correctly configure my asconfig.json?

Adding nothing results in a module that won’t execute:

Error: failed to run main module `build/debug.wasm`

Caused by:
    0: failed to instantiate "build/debug.wasm"
    1: unknown import: `env::abort` has not been defined

Following the instructions from wasi-shim results in a module that won’t compile.

ERROR TS2300: Duplicate identifier 'wasi_abort'.
      :
 1100 │ export function wasi_abort(
      │                 ~~~~~~~~~~
      └─ in ~lib/as-wasi/assembly/as-wasi.ts(1100,17)
    :
 19 │ export function wasi_abort(
    │                 ~~~~~~~~~~
    └─ in ~lib/wasi_internal.ts(19,17)

[dcodeIO]

I guess ideally, both wasi-shim and as-wasi are used alongside, where wasi-shim reconfigures stdlib to use WASI APIs while as-wasi provides additional APIs that are not present in stdlib. Seems this could work well as the default, given that:

• as-wasi depends on wasi-shim already anyway
• Could then remove redundant APIs like
  • Console.* (wasi-shim implements std console.*)
  • Time.* (wasi-shim implements std Date.* and performance.*)
  • Environ.* (wasi-shim implements node-like process.*)
• Whereas as-wasi can focus on additional APIs like file system access
• Then there’s also no need to configure --use directives in as-wasi itself

[dcodeIO]

wasi-shim only overrides APIs already in AS’s stdlib, that is standard-ish JS or, where useful, Node APIs. A console.readAll with no equivalent in JS/Node should remain in as-wasi, unless it can be refactored to map to an actual JS/Node API that is first added to AS stdlib, and then overridden by wasi-shim.