Currently, the wasm code in the extension fails to build, with errors like:
I believe the problem here is that since we moved all of the wasm code, we are no longer properly checking that our code builds correctly.
Two pieces of context to recall:
Component separation
The structure of the Penumbra application code is roughly as follows. Application logic is divided into distinct crates called "components", akin to Cosmos SDK "modules" (but we don't use the m-word, since it already has a meaning in Rust). In each crate, some parts of the code are used both by clients and by the fullnode, while other logic is only used by the fullnode. For instance, the action definitions are used by the client, while the actual action handler is only used on the fullnode.
Each component crate has a component submodule feature-gated by a component feature. All of the async code must live in the component submodule. This way, the crate can be built without the component feature and without pulling in any Tokio deps, async code, etc.
Wasm Cleanup
Our wasm code was originally supposed to be "just bindings", building our set of crates and exposing functions to JS/TS users. However, as we built the web extension, we also ended up having to implement extension-specific logic. This caused problems because we had extension code living outside of the extension repo, and testing and changing it became painful and difficult.
To fix this, we moved all of the wasm code out of the core protocol repo and into the web repo. (Along the way, there was also discussion of splitting up the wasm code into "extension logic" and "just bindings", but this didn't happen, potentially for good reasons, I don't know).
Unexpected Effects
The effect of this change, however, was that we now aren't checking that the core Penumbra crates will build correctly when the component feature is disabled.
There are two problems to solve here, an instant-term (now) problem and a longer-term problem:
[ ] Fix the current compile errors and allow the code to be compiled in wasm.
To do this, I think the workflow would look like:
Check out web repo
Check out core repo in an adjacent directory
Change web repo's wasm crate to have path = "../.. ..." specifiers to the local checkout of core
Change core repo until web repo compiles (use the web repo as the build mechanism)
Change version string in workspace Cargo.toml to 0.68.0-alpha.2
Merge PR with resulting changes into core
Push v0.68.0-alpha.2 tag to core
In web repo, change deps from path = .. to tag = ... with the new tag
[ ] Add or restore a CI check that will ensure that all changes made in this repo will build in a wasm context, so we don't repeat this situation.
turbocrime
commented
4 months ago
Describe the bug
Currently, the wasm code in the extension fails to build, with errors like:
I believe the problem here is that since we moved all of the wasm code, we are no longer properly checking that our code builds correctly.
Two pieces of context to recall:
Component separation
The structure of the Penumbra application code is roughly as follows. Application logic is divided into distinct crates called "components", akin to Cosmos SDK "modules" (but we don't use the m-word, since it already has a meaning in Rust). In each crate, some parts of the code are used both by clients and by the fullnode, while other logic is only used by the fullnode. For instance, the action definitions are used by the client, while the actual action handler is only used on the fullnode.
Each component crate has a
componentsubmodule feature-gated by acomponentfeature. All of the async code must live in thecomponentsubmodule. This way, the crate can be built without the component feature and without pulling in any Tokio deps, async code, etc.Wasm Cleanup
Our wasm code was originally supposed to be "just bindings", building our set of crates and exposing functions to JS/TS users. However, as we built the web extension, we also ended up having to implement extension-specific logic. This caused problems because we had extension code living outside of the extension repo, and testing and changing it became painful and difficult.
To fix this, we moved all of the wasm code out of the core protocol repo and into the web repo. (Along the way, there was also discussion of splitting up the wasm code into "extension logic" and "just bindings", but this didn't happen, potentially for good reasons, I don't know).
Unexpected Effects
The effect of this change, however, was that we now aren't checking that the core Penumbra crates will build correctly when the
componentfeature is disabled.There are two problems to solve here, an instant-term (now) problem and a longer-term problem:
path = "../.. ..."specifiers to the local checkout of coreCargo.tomlto0.68.0-alpha.2v0.68.0-alpha.2tag to corepath = ..totag = ...with the new tag