-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Getting "unresolved import crate::sys::IoSourceState
" error running wasm-pack build
on a project with reqwest/tokio dependencies
#1300
Comments
It seem most likely due to the fact that tokio/mio doesn't support it yet - tokio-rs/tokio#1597 |
It shouldn't need Tokio/Mio's support. CI checks that reqwest can be built for WASM, so it is definitely possible: https://github.com/seanmonstar/reqwest/blob/master/.github/workflows/ci.yml#L292-L323. |
Yes, it does build without tokio but I was planning to use tokio to spawn multiple cooperating tasks which make non blocking api requests. I am curious, if I use blocking client version would the wasm target still compile to use Promise.All to make multiple |
The blocking version of reqwest is not meant to work in WASM. |
@seanmonstar I saw this example - https://github.com/seanmonstar/reqwest/blob/master/examples/wasm_github_fetch/src/lib.rs#L36 and it seem like what I need. Does the return type really have to be If it is possible, I would like to keep everything rust type since I will be making multiple api calls , the result of first api call will be fed into the second one etc. It seem to me the only way to do it is to convert the JsValue back to rust type and pass that to the second api call ? |
The return type of all functions doesn't need to be a |
@seanmonstar I was able to accomplish the wasm integration without needing to use tokio with reqwest. I will close this ticket. Thanks for your help and clarification. |
nope, still not working |
In your Resolver 2 is the default in editions 2021 onwards, but it's possible you have some dependencies with 2018 edition which will make it fallback to version 1 |
it seems like mio does't support wasm32 |
I believe Reqwest will use some Mio features of Tokio if both are imported in the project, and Mio doesn't work on wasm currently. So you can add Similarly to how reqwest does it here: https://github.com/seanmonstar/reqwest/blob/master/Cargo.toml#L100 This file is a great example of dependency management when compiling for various platforms! |
Problem solved? |
I think this issue should be reopened |
这个解决了没 |
This worked for me, though I'm using yew and building with trunk. |
I am also using yew and building with trunk, but unfortunately specifying the resolver did not work for me. Cargo build works fine, but |
Any news/updates on this issue ? Getting the same error:
|
+1 same |
+1 I think this issue is not resolved. Still not work! |
I added reqwest/tokio as a dependency to a webassembly project created via
wasm-pack-template
. When I built the project usingwasm-pack build
command, it is giving me a long list of errors while compilingmio v0.7.13
.The documentation for reqwest suggests that it support's WASM so I am confused why the target "wasm32-unknown-unknown" is failing. I can guess it is because the mio's socket usage (udp/tcp) may not have an equivalent on the browser api but is there any alternate way of building reqwest that would build successfully by using browser's
fetch
?Steps to reproduce:
cargo generate --git https://github.com/rustwasm/wasm-pack-template
and create asample
project.sample
projectwasm-pack build
(full command: "cargo" "build" "--lib" "--release" "--target" "wasm32-unknown-unknown"
)rustc 1.53.0 (53cb7b09b 2021-06-17)
Partial Error below (since the errors list is huge):
Let me know if you need any other information.
The text was updated successfully, but these errors were encountered: