Closed lpotthast closed 7 months ago
Added the #[wasm_bindgen_test]
macro to all remaining tests, including unit-tests. I do not know if unit-test should be kept out though, and running integration-tests only is enough for the wasm case..
I do not know if unit-test should be kept out though, and running integration-tests only is enough for the wasm case..
I think only on integration tests. No need to run unit tests i guess. Although we should probably only have that attribute on wasm target to avoid adding compile time/deps when not needed?
Fixed the CI, thanks!
A few notes:
1) Wasm32 related tests cannot be run that easily, see https://github.com/rustwasm/team/issues/173. You have to use https://rustwasm.github.io/wasm-bindgen/wasm-bindgen-test/usage.html and
wasm-pack
.2) The
criterion
dev-dependency, only used for benchmarks, prohibits any compilation to the wasm32 target when using its default features (rayon in particular). This is now dependant on the targeted architecture.3) Examples could not be compiled to wasm32, or any 32 bit target. The
Claims
struct from bothcustom_hader.rs
andvalidation.rs
had ausize
field which got initialized with a value outside the u32 (usize on wasm32) range. Switching to an explicit u64 type in these structs seemed to be a reasonable fix?4) Most crates provide some
wasm-...
feature, to enable wasm support. This crate uses[target.'cfg(target_arch = "wasm32")'.dependencies]
inside its Cargo.toml. This is obviously easier for users, as there is no feature which could be forgotten. Are there any downsides to this method?5) CI will most likely still not work, as
cargo install wasm-pack
Example
wasm-pack
output: