feat: Add WASM Support #617
Conversation
geofflittle
force-pushed
the
add-wasm-flag
branch
from
cf246d5 to
1c0b72c
Compare
djmitche
left a comment
djmitche
left a comment
There was a problem hiding this comment.
Looking good!
It will be good to update the GitHub actions to do a WASM build, too, so we don't accidentally regress the various cfg conditionals.
| @@ -1,23 +1,22 @@ | |||
| #![cfg(feature = "server-local")] | |||
Cargo.toml
Outdated
| # use native CA roots, instead of bundled | ||
| tls-native-roots = ["ureq/native-certs"] | ||
| # Feature for wasm builds. This enables wasm-compatible storage. | ||
| wasm = ["storage-inmemory"] |
There was a problem hiding this comment.
I think you'll need --no-default-features --features wasm here, but the WASM is implicit from the platform. It might make sense to just document that when building for WASM, only a few features are allowed (among them storage-inmemory) and --no-default-features will be required. Then users building for WASM can select the features they want from among that set (for example, some might want storage-inmemory, while others might want storage-somebrowserdbthing).
Special bonus points if using other features results in a useful error message!
There was a problem hiding this comment.
Got it! I've removed the wasm flag and added some treatment in the README.
Re: your suggestion for a better WASM error message, I found that a build.rs script can't catch a missing --no-default-features flag (i.e., a user building with defaults), because the project's WASM-incompatible dependencies fail to compile before build.rs runs.
Given this, how do you see our detecting the right situation to display an improved error message?
There was a problem hiding this comment.
Given this, how do you see our detecting the right situation to display an improved error message?
Good idea to try to detect in build.rs -- but bummer that it doesn't work. Maybe those special bonus points aren't achievable! No need to spend more time on it.
geofflittle
force-pushed
the
add-wasm-flag
branch
from
1c0b72c to
b083bfa
Compare
geofflittle
force-pushed
the
add-wasm-flag
branch
from
b083bfa to
3acb111
Compare
2 participants
This PR introduces support for compiling to the
wasm32-unknown-unknowntarget, enabling its use in WASM environments.To achieve this, several changes were made:
Cargo.tomlnow uses target-specific dependencies. Forwasm32,tokiois configured with a single-threaded runtime anduuidto use JS-native random number generation. Non-WASM targets retain the multi-threadedtokioruntime.sync-apiprivate feature was introduced to gate synchronization logic that is not WASM-compatible. Existing sync features now depend on this new feature flag. This allows building the core library without the networking and filesystem dependencies required for server sync.storage-inmemoryfeature has been added. A future PR will add this functionality to provide a storage backend that is compatible with WASM environments.build-wasm, has been added to continuously verify that the crate builds successfully for thewasm32target.README.mdhas been updated with a new section explaining how to build the crate for WASM, highlighting the need to disable default features and select compatible ones.