wasm-unknown-unknown/wasm-wasi(p1)

[eberberich]

Hi,

trying to use the CRDT in a Golang setting and experimenting with the above targets. But it doesn't compile because of zstd

zstd-sys@2.0.14+zstd.1.5.7: error: unable to create target: 'No available targets are compatible with triple "wasm32-unknown-unknown"'

Any plans to support general WASM / WASI and not just the TS bindings? Or any hit how to use it in a golang setting?

[zxch3n]

Any plans to support general WASM / WASI and not just the TS bindings?

It's not in our plan right now. Will it make the Go binding work?

how to use it in a golang setting?

Go is not supported because we didn't find a good way to build the FFI from Rust

[eberberich]

@zxch3n Thanks the quick answer!

• Any kind of being able to use wasm generically (WASI seems to be the right thing) could help for integration.

• Yeah it's not the only project that struggles with Golang FFI.

[maldrake]

Hello,

I also took a look at compiling loro for the wasm32-unknown-unknown target just recently. In my case, it's not to support a language binding. I am working on an application that will run in the browser, written in Rust, so I'd like to use the native Rust interface to the loro library, not the typescript bindings. I didn't run into the zstd-sys problem described above. In my case, it looked like the build stopped at the getrandom crate, because the wasm32-unknown-unknown target for getrandom would use an optional backend that requires a feature flag and passing a parameter via RUSTFLAGS.

If I were to try to create a feature flag for loro to compile to the wasm32-unknown-unknown target, would the loro project be interested in considering a pull request? And if so, do you happen to know off-hand if it's likely to be mostly a matter of setting up a feature flag and/or target-specific configuration to propagate down to library dependencies like getrandom, or if there are other incompatibilities between the wasm target and the internals of the loro code base itself?

[zxch3n]

@maldrake You can add this to your dependencies to fix it: getrandom = { version = "0.2.15", features = ["js"] }

[maldrake]

Thank you, @zxch3n! I did so, and the build still stopped at the getrandom crate, but this time with version 0.3.3 of getrandom, which requires a different feature flag to be passed, wasm_js instead of js.

Given that the loro code base seems to be careful to pin the version of getrandom to 0.2.15, I did a little digging to see where the dependency on 0.3.3 is coming from. According to cargo tree -e features -i getrandom@0.3.3, it looks like the newer version of getrandom is being included through the ahash crate. I took a look at the source for the ahash crate, and it does look like their Cargo.toml does, indeed, reference version 0.3.1. According to git blame, it looks like that change was introduced fairly recently, about 2 months ago.

I don't think I can use the same trick of including a line like getrandom = { version = "0.3.3", features = ["wasm_js"] } in my Cargo.toml file, though, as I can't have duplicate dependency declarations for getrandom.

[TimothyMischief]

Thank you, @zxch3n! I did so, and the build still stopped at the getrandom crate, but this time with version 0.3.3 of getrandom, which requires a different feature flag to be passed, wasm_js instead of js.

Given that the loro code base seems to be careful to pin the version of getrandom to 0.2.15, I did a little digging to see where the dependency on 0.3.3 is coming from. According to cargo tree -e features -i getrandom@0.3.3, it looks like the newer version of getrandom is being included through the ahash crate. I took a look at the source for the ahash crate, and it does look like their Cargo.toml does, indeed, reference version 0.3.1. According to git blame, it looks like that change was introduced fairly recently, about 2 months ago.

I don't think I can use the same trick of including a line like getrandom = { version = "0.3.3", features = ["wasm_js"] } in my Cargo.toml file, though, as I can't have duplicate dependency declarations for getrandom.

I opened a new issue for the root cause, but if you're looking for a work around in the mean time I have successfully compiled for wasm by cloning a local copy of ahash-0.8.11 and patching in the local version with:

[patch.crates-io]
ahash = { path = "vendor/ahash-0.8.11" }

You'll just have to clear any reference to newer versions of ahash from your cargo lock.