Bluefinger / bevy_turborand

A plugin to enable random number generation for the Bevy game engine.
Apache License 2.0
35 stars 5 forks source link

Web build stopped working after migrating to Bevy 0.13 #15

Closed GitGhillie closed 6 months ago

GitGhillie commented 6 months ago

The app will not load, with error Uncaught TypeError: Failed to resolve module specifier "env". Relative references must start with either "/", "./", or "../". The app will load normally after commenting out .insert_resource(GlobalRng::new()). Or by changing back to Bevy to 0.12 and Bevy_turborand to 0.7.

I'm building with cargo build --release --target wasm32-unknown-unknown. Then wasm-bindgen --no-typescript --out-name wasm_repro --out-dir wasm --target web target/wasm32-unknown-unknown/release/wasm_repro.wasm.

See reproducer: https://github.com/GitGhillie/wasm_repro

Looks like nothing really changed in bevy_turborand after updating to Bevy 0.13, but it's the start of the trail for me. Let me know if I missed anything!

Bluefinger commented 6 months ago

Huh, weird. I have the CI to check the wasm build on the Ubuntu actions, so something must be going on with this to cause the issue. I'll give this one a poke and see what I find.

Bluefinger commented 6 months ago

I have a fix. Currently bevy_turborand does not make an assumption with what environment you are loading your wasm in to, as there's like wasm-bindgen and stdweb, etc. So for one of its dependencies, instant, you'll need to add to your Cargo.toml this:

[target.'cfg(target_arch = "wasm32")'.dependencies]
instant = { version = "0.1", features = ["wasm-bindgen"] }

This should allow bevy_turborand to load correctly. Hope this helps!

GitGhillie commented 6 months ago

Thank you! That worked. I guess a long-term solution would be for something like that to be in the Cargo.toml of bevy_turborand?

Bluefinger commented 6 months ago

I think this is more a case of documentation for building into wasm, as I don't want to necessarily force things to be wasm-bindgen only. The problem is not really bevy_turborand itself, but one of its deps that needs toggling certain features for compatibility. Then again, I need to check how people are using and deploying Bevy stuff into wasm.

GitGhillie commented 6 months ago

That makes sense, I guess I was mostly confused because it worked without the fix on 0.12.

Personally I'd make instant with wasm-bindgen feature a default feature of bevy_turborand if the target is wasm (if it's even possible to specify it like that in a Cargo.toml). Because wasm-bindgen does seem to be the most common way with Bevy.

Anyways it's up to you, feel free to close the issue when you see fit :)

Bluefinger commented 6 months ago

I've decided to go with documenting how to get turborand to build in wasm, as for that, I don't want to assume much on what is used, wasm-bindgen and what not. For bevy_turborand, given that Bevy is built with wasm-bindgen in mind for the web, I think it is a clearer case for enabling it by default for bevy_turborand.

I made a new patch release to resolve this with bevy_turborand, so this issue should be fully resolved now without workarounds.

GitGhillie commented 6 months ago

Sounds good! Thank you for looking into this