[GH-ISSUE #1133] Can this library run in WASM? #610

New issue

Open

opened 2026-03-15 23:26:33 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 23:26:33 +03:00

Owner

Originally created by @amaury1093 on GitHub (Jun 10, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1133

Is your feature request related to a problem? Please describe.

I'm trying to deploy my code to Cloudfare Workers, which run JS & WASM. Specifically, I'm using the async-std-resolver crate, but right now compilation fails.

error: Unsupported target OS! Create an issue: https://github.com/svartalf/hostname/issues/new
  --> /Users/amaurymartiny/.cargo/registry/src/github.com-1ecc6299db9ec823/hostname-0.3.1/src/lib.rs:81:9
   |
81 |         compile_error!("Unsupported target OS! Create an issue: https://github.com/svartalf/hostname/issues/new");
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0433]: failed to resolve: use of undeclared type or module `sys`
   --> /Users/amaurymartiny/.cargo/registry/src/github.com-1ecc6299db9ec823/hostname-0.3.1/src/lib.rs:105:5
    |
105 |     sys::get()
    |     ^^^ use of undeclared type or module `sys`

error: aborting due to 2 previous errors

Describe the solution you'd like

Add a feature flag which would allow targetting this library to WASM.

Describe alternatives you've considered

n/a

Additional context

Right now, it relies on resolv-conf, which iiuc can't be compiled to wasm. Maybe returning an empty-file stub in wasm would work?

Originally created by @amaury1093 on GitHub (Jun 10, 2020). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1133 **Is your feature request related to a problem? Please describe.** I'm trying to deploy my code to Cloudfare Workers, which run JS & WASM. Specifically, I'm using the `async-std-resolver` crate, but right now compilation fails. ``` error: Unsupported target OS! Create an issue: https://github.com/svartalf/hostname/issues/new --> /Users/amaurymartiny/.cargo/registry/src/github.com-1ecc6299db9ec823/hostname-0.3.1/src/lib.rs:81:9 | 81 | compile_error!("Unsupported target OS! Create an issue: https://github.com/svartalf/hostname/issues/new"); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0433]: failed to resolve: use of undeclared type or module `sys` --> /Users/amaurymartiny/.cargo/registry/src/github.com-1ecc6299db9ec823/hostname-0.3.1/src/lib.rs:105:5 | 105 | sys::get() | ^^^ use of undeclared type or module `sys` error: aborting due to 2 previous errors ``` **Describe the solution you'd like** Add a feature flag which would allow targetting this library to WASM. **Describe alternatives you've considered** n/a **Additional context** Right now, it relies on `resolv-conf`, which iiuc can't be compiled to wasm. Maybe returning an empty-file stub in wasm would work?

kerem added the

crate:resolver

platform:WASM

labels

2026-03-15 23:26:33 +03:00

kerem commented

2026-03-15 23:26:56 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 10, 2020):

What is the context for this runtime? A browser?

The proto crate has been used in WASM, but I don’t know what the expectation of the runtime would be in a WASM environment for the resolver. Would WASI be at least a requirement for network access, to be run in a Node environment?

@bluejekyll commented on GitHub (Jun 10, 2020): What is the context for this runtime? A browser? The proto crate has been used in WASM, but I don’t know what the expectation of the runtime would be in a WASM environment for the resolver. Would WASI be at least a requirement for network access, to be run in a Node environment?

kerem commented

2026-03-15 23:27:01 +03:00

Author

Owner

@amaury1093 commented on GitHub (Jun 10, 2020):

What is the context for this runtime? A browser?

In my case, it's Cloudfare Workers. According to their blog, the runtime context is their edge compute architecture, and it's compatible the W3C Service Worker API.

I believe a Node environment shouldn't be expected (e.g. I don't think resolver should in this case read config files on the filesystem), but for network access the runtime context can be assumed to be compatible with either WASI or Service Worker API (ideally both, e.g. if they share the same API for network access).

@amaury1093 commented on GitHub (Jun 10, 2020): > What is the context for this runtime? A browser? In my case, it's Cloudfare Workers. According to [their blog](https://blog.cloudflare.com/introducing-cloudflare-workers/), the runtime context is their edge compute architecture, and it's compatible the W3C Service Worker API. I believe a Node environment shouldn't be expected (e.g. I don't think resolver should in this case read config files on the filesystem), but for network access the runtime context can be assumed to be compatible with either WASI or Service Worker API (ideally both, e.g. if they share the same API for network access).

kerem commented

2026-03-15 23:27:06 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 10, 2020):

I haven't investigated this. We have a few options. Right now trust-dns-resolver supports two Runtimes, Tokio and async-std.

The options I see are either adding support for WASM/WASI/ServiceWorkerAPI for TCP/UDP socket layer support to one of the supported runtimes.
Use the generic type parameters in the resolver to pass in a custom Runtime or ConnectionProvider that would implement the appropriate socket creation methods.
Some combination of both of those.

@bluejekyll commented on GitHub (Jun 10, 2020): I haven't investigated this. We have a few options. Right now trust-dns-resolver supports two Runtimes, `Tokio` and `async-std`. - The options I see are either adding support for WASM/WASI/ServiceWorkerAPI for TCP/UDP socket layer support to one of the supported runtimes. - Use the generic type parameters in the resolver to pass in a custom `Runtime` or `ConnectionProvider` that would implement the appropriate socket creation methods. - Some combination of both of those.

kerem referenced this issue

2026-03-16 02:13:00 +03:00

[PR #617] [MERGED] make ClientResponse public in client module #1559