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
feat: add support for wasm #1040
Conversation
We'll want to add a wasm32 build to CI - even if we aren't going to run tests we'll want to know the build isn't broken. |
Adds support for compiling to WASM environments that provide JS via wasm-bindgen. Because there's no standardized socket API the caller must provide a connection that implements AsyncRead/AsyncWrite to connect_raw.
Adds a CI job for ensuring the tokio-postgres crate builds on the wasm32-unknown-unknown target without the default features.
This looks good to me - anything you're still planning to add or should we merge? |
I still want to see if the addition of |
The resolver selection is local to each workspace. Rather than unconditionally enabling the That should remove the need for resolver 2 as well. |
Agreed about the The current solution of excluding socket2 on non-wasm targets still works as expected for projects using resolver 1 because resolver 1 includes all the dependencies regardless of target. If adding an extra default feature is off the table this could be a workaround where resolver 2 is required for wasm support but not necessary on other platforms. |
The socket2 dependency can be unconditionally disabled on wasm - the only thing gated by the feature would be the getrandom feature (which is a no-op on not-wasm so it shouldn't matter if people are using resolver 2 or not). |
Yeah I agree with you on putting The two approaches outlined would be making it a default feature, which would be a breaking change for people using tokio-postgres without default features. Or adding resolver 2 back to the workspace and requiring people using WASM to use the new resolver in their workspace as well, introducing no breaking change for non-wasm users. |
[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
socket2 = { version = "0.5", features = ["all"] } should be sufficient without any resolver customization I think? |
On resolver 1 that'll still include socket2 for wasm targets because |
I don't think that's correct - resolver 1 vs 2 affects how features of enabled dependencies are unified across cfg-specific dependencies. Platform dependent crates have always been supported. See for example native-tls which has cfg'd dependencies on schannel and security framework crates that wouldn't build off of their native platform. |
Oh wow, yeah I totally had some wires cross in my head 😅. With resolver 1 the issue is that tokio gets compiled with features (including socket2, which is where I made the mistake) that aren't compatible with WASM. By running
The features are coming from the dev dependencies which is an issue with resolver 1, so to work around that without using resolver 2 just for the CI check I hackily added a sed to ignore the dev dependencies for the workflow. |
build's red |
Adds support for compiling to WASM environments that provide JS via wasm-bindgen. Because there's no standardized socket API the caller must provide a connection that implements
AsyncRead
/AsyncWrite
toconnect_raw
.The motivation for this is an open PR to the Rust framework for Cloudflare Workers where Cloudflare recently announced support for TCP sockets.