-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WASM support #17
Comments
There currently aren't any plans to add more web/nodejs-specific targets AFAIK. There's been ideas of maybe we should in the past, but currently there are now plans to add more. Ideally this crate would support the wasm32 targets without manually opting in to a feature, but requiring one isn't necessarily the end of the world. |
The simplest option would just be to deprecate the I guess we should avoid releasing version 1.0 before addressing this, but don't see much point worrying about it yet. |
As per koute/stdweb#318 Thus the question is: should we deprecate |
I suggest we don't deprecate Note regarding possible |
I guess we can close this issue. |
Currently for
wasm32-unknown-unknown
target we have two featuresstdweb
andwasm-bindgen
. In future the following changes can happen:stdweb
will become compatible withwasm-bindgen
, which will allow us to deprecatestdweb
feature. See: Building on top of wasm-bindgen? koute/stdweb#318wasm32-unknown-unknown
target. See: New targets rustwasm/team#38Following those changes may cause
getrandom
build breakage for some users, e.g. even if we'll writestdweb = ["wasm-indgen"]
inCargo.toml
it may break build for users of olderstdweb
versions. Thus I believe we should think about how those changes can be handled in future.I see 3 options:
rand
crates.cc @koute @alexcrichton
The text was updated successfully, but these errors were encountered: