Fix Wasm target gates for engine-side Wasm operation

[arctic-hen7]

This issue is reporting a bug in the code of Perseus. Details of the scope will be available in issue labels.
The author described their issue as follows:

Right now, attempting to use engine-side Perseus in a Wasm environment will lead to errors that look something like the detonation of a nearby star. This should be trivially fixable by changing the existing #[cfg(target_arch = "wasm32")] and inverse target-gates to something that specifically recognizes only browser-side Wasm. Exactly what this is is another matter.

The steps to reproduce this issue are as follows:

Try to compile and run engine-side Perseus on something like a Cloudflare worker.

A minimum reproducible example is available at <>.

• Hydration-related: false
• The author is willing to attempt a fix: true

Tribble internal data

dHJpYmJsZS1yZXBvcnRlZCxDLWJ1ZyxhdXRob3Itd2lsbGluZy10by1pbXBs

[arctic-hen7]

Due to the lack of a #[cfg(target = "wasm32-unknown-unknown")]-style conditional compilation predicate (to my knowledge), this is very possibly going to become quite grotesque, and it is used a lot in the codebase. If anyone has a particularly elegant way of doing this, that would be greatly appreciated! (My attention is with the capsules right now.)

[lukechu10]

Due to the lack of a #[cfg(target = "wasm32-unknown-unknown")]-style conditional compilation predicate (to my knowledge), this is very possibly going to become quite grotesque, and it is used a lot in the codebase. If anyone has a particularly elegant way of doing this, that would be greatly appreciated! (My attention is with the capsules right now.)

Even if that were possible, I don't think that would be a good solution. Instead, maybe have the perseus CLI set a custom cfg flag via the command line and use #[cfg(ssr)] which is nice and short.

[arctic-hen7]

This is exactly what I was thinking, but perhaps a build script would be cleaner?

[lukechu10]

This is exactly what I was thinking, but perhaps a build script would be cleaner?

The problem with build-scripts is that they only affect the current crate that is being compiled, whereas setting a flag from the CLI will affect all the crates being compiled. You probably want the latter because these feature gates would also be used in perseus and other dependencies.

[arctic-hen7]

Ah I hadn't understood that. Thanks!

[arctic-hen7]

This is fixed in the latest commit, but I haven't explicitly tested support for compiling the engine to Wasi or the like. Since this issue pertains to the target gates themselves, I'll close this.

[arctic-hen7]

Pretty sure actually compiling Perseus to Wasi is blocked by rust-lang/socket2#268.