hero_lifecycle forces tokio/full unconditionally — breaks wasm32 consumers (e.g. hero_collab_app) #156

New issue

Open

opened 2026-06-15 23:17:16 +00:00 by sameh-farouk · 0 comments

sameh-farouk commented

2026-06-15 23:17:16 +00:00

Member

Problem

hero_lifecycle declares tokio = { features = ["full"] } unconditionally in its Cargo.toml. The full feature pulls in tokio/net → mio, which does not compile for wasm32-unknown-unknown:

error: This wasm target is unsupported by mio

Any WASM crate that (transitively) depends on hero_lifecycle therefore cannot build for wasm32.

Impact

Surfaced while migrating hero_collab to oschema-first: hero_collab_app (Dioxus/WASM admin dashboard) cannot produce a wasm build because it pulls hero_lifecycle. The app's own code is wasm-clean (cargo check on the host target is green and it adds no deps) — the blocker is purely hero_lifecycle's unconditional tokio/full. Reproduces at HEAD (pre-existing, not introduced by the collab migration).

Suggested fix

Gate the heavy tokio features behind a target/feature so wasm consumers get a minimal tokio (or none). E.g. [target.'cfg(not(target_arch = "wasm32"))'.dependencies] tokio = { features = ["full"] } + a slim [target.'cfg(target_arch = "wasm32")'.dependencies] tokio = { features = ["sync", "macros"] }, or a server/native feature that the binary crates enable and wasm crates don't.

Note (separate, toolchain)

There is also a local dx (0.7.4) vs project dioxus (0.7.9) version skew that mis-selects the standalone-gated [[bin]] during dx build — a toolchain/version alignment issue, not a code one. Mentioned for completeness; the tokio/full issue is the code-level root cause.

Ref: hero_collab oschema migration (lhumina_code/hero_collab#78); hero_collab_app wasm build.

## Problem `hero_lifecycle` declares `tokio = { features = ["full"] }` **unconditionally** in its Cargo.toml. The `full` feature pulls in `tokio/net` → `mio`, which does not compile for `wasm32-unknown-unknown`: ``` error: This wasm target is unsupported by mio ``` Any WASM crate that (transitively) depends on `hero_lifecycle` therefore cannot build for `wasm32`. ## Impact Surfaced while migrating **hero_collab** to oschema-first: `hero_collab_app` (Dioxus/WASM admin dashboard) cannot produce a wasm build because it pulls `hero_lifecycle`. The app's own code is wasm-clean (`cargo check` on the host target is green and it adds no deps) — the blocker is purely `hero_lifecycle`'s unconditional `tokio/full`. Reproduces at HEAD (pre-existing, not introduced by the collab migration). ## Suggested fix Gate the heavy tokio features behind a target/feature so wasm consumers get a minimal tokio (or none). E.g. `[target.'cfg(not(target_arch = "wasm32"))'.dependencies] tokio = { features = ["full"] }` + a slim `[target.'cfg(target_arch = "wasm32")'.dependencies] tokio = { features = ["sync", "macros"] }`, or a `server`/`native` feature that the binary crates enable and wasm crates don't. ## Note (separate, toolchain) There is also a local `dx` (0.7.4) vs project dioxus (0.7.9) version skew that mis-selects the `standalone`-gated `[[bin]]` during `dx build` — a toolchain/version alignment issue, not a code one. Mentioned for completeness; the tokio/full issue is the code-level root cause. Ref: hero_collab oschema migration (lhumina_code/hero_collab#78); hero_collab_app wasm build.