wasm-terminal: `w.resolve is not a function` error introduced from v0.11.0

[taybenlor]

I've been messing around with running the python WAPM package using wasm-terminal in a similar way to how WebAssembly.sh works. I kept getting plagued with w.resolve is not a function from the process worker (once it's been blobified) on running. Eventually I fixed this by downgrading to v0.10.0 after noticing that WebAssembly.sh uses v0.10.0 and everything just worked!

I'm having a lot of difficulty creating a clean reproduction of this bug. On my own project I have nailed it down to a difference between v0.10.2 and v0.11.0. I tried installing WebAssembly.sh locally but have not been able to get it to build. However I suspect that if you upgraded WebAssembly.sh to use v0.11.0 you would see the same issue when running the python WAPM package.

It's also difficult to trace down where the error is actually happening, since I'm working with the minified version of the process worker.

Sorry for the vague bug report!

[taybenlor]

If you have suggestions for how I could help with this I would love to hear them. Happy to contribute, but would need guidance as I'm not particularly familiar with Web Assembly or the wasmer tools.

[syrusakbary]

Thanks for opening the issue! We will investigate shortly

[jrandall]

I have a similar issue with the ls command from WAPM. ls works just fine if I downgrade wasm-terminal to 0.10.2 but versions 0.11.0 and 0.12.0 both give an error:

0.11.0:

TypeError: v.resolve is not a function
    at blob:http://localhost:8080/36851808-9ee7-44d0-9c6d-e96acbbda5aa:474:407
    at blob:http://localhost:8080/36851808-9ee7-44d0-9c6d-e96acbbda5aa:174:166
    at h.wasiImport.<computed> (blob:http://localhost:8080/36851808-9ee7-44d0-9c6d-e96acbbda5aa:483:223)
    at _ZN3std3sys4wasi2fs11metadata_at17h401af42b81091b13E (<anonymous>:wasm-function[1513]:0xcd34c)
    at _ZN3std3sys4wasi2fs4stat17h852f933c1453b20bE (<anonymous>:wasm-function[1522]:0xce4b9)
    at _ZN3std4path4Path6is_dir17h216978d6fe618bfaE (<anonymous>:wasm-function[1601]:0xd496d)
    at _ZN5uu_ls6uumain17ha0e27d477406f2f0E (<anonymous>:wasm-function[345]:0x2cb6d)
    at _ZN6uutils4main17h4dfa95b597823ff6E (<anonymous>:wasm-function[49]:0x42fd)
    at _ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17hbfd8e7ea8f500786E (<anonymous>:wasm-function[33]:0x1ea2)
    at _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17hc121d5dc89b45d51E (<anonymous>:wasm-function[1614]:0xd5010)

This is followed by ls: Unknown Error

On 0.12.0 the error is essentially the same just with a different minified variable name:

TypeError: u.resolve is not a function
    at blob:http://localhost:8080/c29033ac-c08b-4414-9f14-94f505d5ce32:369:359
    at blob:http://localhost:8080/c29033ac-c08b-4414-9f14-94f505d5ce32:124:62
    at _ZN3std3sys4wasi2fs11metadata_at17h401af42b81091b13E (<anonymous>:wasm-function[1513]:0xcd34c)
    at _ZN3std3sys4wasi2fs4stat17h852f933c1453b20bE (<anonymous>:wasm-function[1522]:0xce4b9)
    at _ZN3std4path4Path6is_dir17h216978d6fe618bfaE (<anonymous>:wasm-function[1601]:0xd496d)
    at _ZN5uu_ls6uumain17ha0e27d477406f2f0E (<anonymous>:wasm-function[345]:0x2cb6d)
    at _ZN6uutils4main17h4dfa95b597823ff6E (<anonymous>:wasm-function[49]:0x42fd)
    at _ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17hbfd8e7ea8f500786E (<anonymous>:wasm-function[33]:0x1ea2)
    at _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17hc121d5dc89b45d51E (<anonymous>:wasm-function[1614]:0xd5010)
    at _ZN3std9panicking3try7do_call17h20c714e9d0d4b4c1E (<anonymous>:wasm-function[1634]:0xd599b)

Those were both on Chrome 89.0.4389.90 on Linux.

On Firefox 87.0 on Linux, with wasm-terminal 0.12.0 I get a bit more information in the call stack:

TypeError: v.resolve is not a function
    path_filestat_get webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1021
    Y webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1003
    start webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1031
    run webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1034
    d webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:844
    c webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:843
    f webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    promise callback*k webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    rg webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    rg webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    run webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1033
    start webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1038
    d webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:844
    c webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:843
    rg webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    rg webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    start webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1038
    _spawnProcess webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1055
    d webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:844
    c webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:843
    f webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    promise callback*k webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    rg webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    rg webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    _spawnProcess webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1055
    _tryToSpawnProcess webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1054
    d webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:844
    c webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:843
    rg webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    rg webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    _tryToSpawnProcess webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1054
    runCommand webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1053
    d webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:844
    c webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:843
    f webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    promise callback*k webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    rg webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    rg webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    runCommand webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1051
    prompt webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1076
    d webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:844
    c webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:843
    f webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    promise callback*k webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    rg webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    rg webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:842
    prompt webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1074
    open webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1081
    setTimeout handler*al</b.prototype.open webpack:///./node_modules/@wasmer/wasm-terminal/lib/optimized/wasm-terminal.esm.js?:1080
    <anonymous> webpack:///./app.js?:57
    js http://localhost:8080/dist/bundle.js:19
    __webpack_require__ http://localhost:8080/dist/bundle.js:291
    <anonymous> http://localhost:8080/dist/bundle.js:343
    <anonymous> http://localhost:8080/dist/bundle.js:345

wasm-terminal 0.10.2 works on both Chrome and Firefox with no issues (i.e. it displays the wasmFs filesystem listing to the terminal and does not print a console error). Versions 0.11.0 and up do not print any ls output to the terminal and instead give the above console errors.

[corwin-of-amber]

@syrusakbary This is definitely a problem with the path bindings. I am like 70% sure that I've hit this problem even without wasm-terminal, and it was some problem with Parcel filling in an empty implementation of path. Here the bundler seems to be Webpack, so it may be fixed via the Webpack config.

In general: are WAPM packages universal in the sense that they can run on any version of Wasmer-js? In the past, I got the impression that the answer is no, because changes in wasi-sdk tend to require changes in @wasmer/wasi, which means it cannot be backwards-compatible.

[sfranzyshen]

any ideas ... work arounds ... tips ... anything? or are we limited to only using 0.10.0 ...

[syrusakbary]

We are on the way to deprecating this repo in favor of a pure-Rust implementation targeting Node and the browsers via wasm-bindgen. All APIs should work the same with the same provided API. But that's why you are not seeing that much progress on this repo.

We are already working on the new version, and updates should follow :)

[taybenlor]

Thanks @syrusakbary! It’d be great to see the browser side of Wasmer get some love. A Rust implementation that works in both Node and Browsers sounds great.

[sfranzyshen]

can you please give any additional information about the plans to "replace" the functionality of this package with something new? I tried to look over the wasmer/lib/js-api/ pull request and do not see how I could edit code of something that was built based on this package with the new ... maybe I am missing something ... but it seems to me that @wasmer is being abandoned (or deprecated) and anyone working with @wasmer/wasi, @wasmer/wasm-terminal or @wasmer/wasmfs are SOL? am I wrong?

[syrusakbary]

Thanks for chiming in @sfranzyshen!

@wasmer is not being abandoned, in fact is being revamped! Just with a bit more optimal implementation. We will preserve the same API that the current wasmer-js has. That means, for using WASI, for example will be done through the same API and package in NPM.

For the filesystem layer, it's likely to no longer be based on memfs (like For @wasmer/wasmfs was), so the API on that case might differ a bit. Regarding wasm-terminal, it's likely that the API will be improved, but still using xterm.js.

[sfranzyshen]

@syrusakbary Thanks for that response ... puts me more at easy to know @wasmer-js will still have a future ...

[sfranzyshen]

Maybe things have once again changed ... unless you are developing in RUST ... Javascript support seems to have been abandoned ... oh well maybe another project will pickup the wasmer-js vacuum ...

[sfranzyshen]

https://mnt.io/2021/10/04/i-leave-wasmer/

[john-sharratt]

@syrusakbary can you point me to the RUST implementation repo - super interested in how this goes

[syrusakbary]

Closed the issue by mistake. The Rust implementation lives in the Wasmer repo and uses wasm-bindgen to run in the browser.

You can check the browser/node tests here: https://github.com/wasmerio/wasmer/blob/master/lib/wasi/tests/js.rs

[corwin-of-amber]

Thanks @syrusakbary; perhaps you want to update the Language Integrations part of the README (https://github.com/wasmerio/wasmer#-language-integrations) since it still points to the @wasmer NPM org as the location of JS support.

[Michael-F-Bryan]

I don't believe this is relevant any more because the @wasmer/wasi package was rewritten on top of Wasmer 4.0 and WASIX, and renamed to @wasmer/sdk.