-
Notifications
You must be signed in to change notification settings - Fork 518
-
Notifications
You must be signed in to change notification settings - Fork 518
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
Feature flag for the new wasm javascript support? #334
Comments
I didn't check yet, but my code is probably running into this too. I'm really wondering why there's no stronger push for an actual wasm32-web target. Solving what is essentially a different target through features is just weird and the whole ecosystem is suffering because of it. And it could allow for std to directly use wasm-bindgen as well, such as support for println!(), dbg!(), panic printing and co. |
Yeah fully agree, that would be better for everyone. Likely are some discussions or plans somewhere as WASM in Rust is a pretty hot and active topic, and with a specific rust wasm working group also. But in the meantime think having feature flags in the crates is likely the best one can do for now? |
Interesting, I really thought that the fact that it was gated to the I'll publish a feature-flagged version tomorrow, unless folks come up with a better option. |
Well theoretically there are like 4 different targets that matter:
|
@quodlibetor yes can try it out. right now that PR fails on CI though |
@repi it's failing because I forgot to add the |
All of these type of lines in the crate need to be feature gated behind the new feature also for it to compile: #[cfg(all(target_arch = "wasm32", not(target_os = "emscripten")))]
extern crate wasm_bindgen;
#[cfg(not(all(target_arch = "wasm32", not(target_os = "emscripten"))))]
pub fn now() -> DateTime<Utc> { but with that fixed this should work well for our use case and doesn't pull in the wasm-bindgen dependencies, thx! |
Thanks! That's good news. |
I've updated that pr with what appears to be actually correct code, I'll release tonight unless I get some pushback that a release is a bad idea. |
In the new 0.4.8 release javascript/browser WASM support was added in #331. Would it be possible get a feature flag for this support, instead of having it always on?
This support and the dependencies on
wasm-bindgen
andjs-sys
when building forwasm32-unknown-unknown
only works in a browser environment and not when running wasm outside of a browser, which is what we (and others also) do.Togglable javascript wasm support through a feature flag could be nice for those that do not use wasm also as then they can disable that feature flag (can be on by default though) and not have get these extra dependencies (unused by in their Cargo.lock files):
I guess this is a general issue with the general and non-specific
wasm32-unknown-unknown
target, it doesn't specify which environment it will be run in (compared to saywasm32-wasi
orwasm32-unknown-emscripten
) though haven't run into that many other issues like this, likely because quite a few other crates have feature flags forstdweb
or similar.The text was updated successfully, but these errors were encountered: