I’ve been looking in the docs and I found the phrase “[zomes] should contain either pre-compiled WASM, or the source code and instructions to generate WASM”. But there are no instructions on what that looks like or examples to follow.
Are there any zome.json properties that need to be declared to do this? What about the name of the WASM file & folder structure? I can confirm that:
if the WASM file is placed adjacent to zome.json, no code attribute is generated for the DNA bundle and compilation fails.
if the WASM file is manually specified in the code attribute it complains about invalid format, so that’s definitely not right…
if the WASM file is placed in a codesubdirectory adjacent to zome.json, an empty object is present for the code attribute in the DNA bundle.
@pospi honestly long term i’m not convinced the whole “build steps in JSON” thing is a good idea because it funnels everything through the underlying assumptions that rust makes about what you want to be doing (e.g. runtime environment variables are very awkward to handle)
for example look at how CARGO_TARGET_DIR gets juggled in the template zomes:
my personal opinion is that the ideal world simply uses bash/nix for steps, probably in a “hooks” setup similar to how hn-release-cut allows scripts to be injected, and then we build up richer tooling around the artifact handling - which should probably be carefully aligned with the bundle.toml side of things too
Looping back as I’d like to start wiring up the “Personas” app into our codebase, but I’m not sure how to do this without cloning it into an adjacent directory and making our project’s .hcbuild files target its artifacts. Is there a better way to reference these, preferably from precompiled WASM binaries?