fix: compile wasm vs native features with custom cfg to prevent dupe features

[NathanFlurry]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[NathanFlurry]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• fix(rivetkit): preserve internal bridge errors #4993
• fix(rivetkit): remove deprecated actor options #4992
• fix(rivetkit): fix default spawn engine behavior #4989
• chore: fix compile warnings #4988
• fix: compile wasm vs native features with custom cfg to prevent dupe features #4982 👈 (View in Graphite)
• chore: remove setPreventSleep #4981
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[claude]

PR Review: fix: compile wasm vs native features with custom cfg to prevent dupe features

Overview

This PR solves a real Cargo feature-unification problem: when rivetkit-wasm (which enables wasm-runtime) and rivetkit-napi (which enables native-runtime) both live in the workspace, Cargo unifies their features, causing both to be active simultaneously. The fix introduces build.rs scripts that compute the effective runtime/transport via custom cfg flags, collapsing the additive feature set into exactly one mode per build unit.

The approach is sound and idiomatic for this class of problem.

---

Correctness

rivetkit-core/build.rs cfg logic:

• wasm-runtime only → rivetkit_wasm_runtime
• native-runtime only → rivetkit_native_runtime
• Both active → rivetkit_native_runtime (native wins)
• Neither → rivetkit_native_runtime (safe default)

This is correct.

envoy-client/build.rs cfg logic:

Edge case: if only wasm-transport is enabled on a native target (not wasm32), the first condition (native_transport && !is_wasm) is false and the second (wasm_transport) is true, so rivet_envoy_wasm_transport gets set — which may cause browser-native APIs to be compiled into a non-wasm build. Low practical risk since only rivetkit-wasm enables wasm-transport and it only targets wasm32, but a comment in build.rs documenting this assumption would be defensive.

lib.rs compile_error update:

The mutual-exclusion guard now only fires on wasm32 when both features are active. On native, both can coexist (native wins via build.rs). Consistent with the new model. ✓

---

Potential Issues

1. No guard for wasm-transport active on native targets.

In transport.rs, if rivet_envoy_wasm_transport is set on a non-wasm32 build, the wasm module will be compiled in and may fail due to browser WebSocket APIs. Consider adding a compile_error! for all(rivet_envoy_wasm_transport, not(target_arch = "wasm32")).

2. wasm-bindgen-futures promoted from target-gated to feature-gated.

It was previously a target_arch = "wasm32" dependency; it is now enabled by the wasm-runtime feature. On a native build where feature unification activates both native-runtime and wasm-runtime, wasm-bindgen-futures will enter the native dep graph. It compiles safely on native, but verify that all usage sites are behind #[cfg(rivetkit_wasm_runtime)] so no browser-specific code paths are reachable on native.

3. default-members hardcodes rivetkit-rust package names.

New crates under engine/packages/* are covered by the glob, but rivetkit-rust/packages/ only lists three packages explicitly. A new rivetkit-rust crate added without updating this list will be silently excluded from the default cargo check surface. A short comment noting this maintenance obligation would help.

---

Good Patterns

• cargo:rustc-check-cfg is correctly declared for all custom cfgs, preventing unknown-cfg compiler warnings. ✓
• transport.rs consolidation is cleaner than the previous per-feature pub use block in mod.rs. ✓
• Dead fallback code removed: the cfg(not(any(feature = "native-runtime", feature = "wasm-runtime"))) stubs in runtime.rs that duplicated the native path are gone. ✓
• CLAUDE.md update accurately captures the new invariant. ✓
• Moving tokio out of the wasm-only target dep in rivetkit-wasm and adding the sync feature is consistent with the crate now being buildable in a host context for testing. ✓

---

Summary

The core approach is correct and well-executed. Items to address before landing:

• Consider a defensive compile_error! in transport.rs for wasm-transport active on non-wasm32.
• Verify wasm-bindgen-futures usage sites are all behind #[cfg(rivetkit_wasm_runtime)].
• Add a comment near default-members noting that explicit rivetkit-rust/packages entries require manual updates when new crates are added.

No blocking issues. The custom-cfg strategy is the right tool for this problem.