[wasm] wasm crate should provide useful types

[turbocrime]

the wasm crate should produce an npm package that exports useful types.

the wasm crate build currently emits a useless declaration asserting everything is "any" type.

the completely separate wasm-ts wrapper package in the web repo is essentially a shim that reintroduces type information. requiring manual type annotation by a separate wrapper package is incorrect.

type declarations should be colocated with the implementation, even if that requires additional tooling or manual annotation inside the rust code.

[TalDerei]

https://dawchihliou.github.io/articles/share-rust-types-with-typescript-for-webassembly-in-30-seconds

[turbocrime]

i've spoken to @grod220 about tsify, but iirc they suggested it was unsuitable for some reason. would be interesting to get some detail on what blocks tsify, vs what might block ts-rs (seems to have serde integration but no wasm bindgen integration) or wasm bindgen's typescript_type and typescript_custom_section which could be used for manual annotation

[grod220]

This is a very worthwhile thing to explore again. The first attempt in going through this, it became simply easier to do type annotation+validation in wrappers given we need to associate the any's with the automatically generated BufBuild types. But it’s sad we cannot simply inherit all of the correct types (somehow).

• Tsify

  • The best rust-side solution that exists. However, all fields (recursively) must have those Rust attributes. For example, take WasmPlanner. We could not give it the tsify annotations given Serialize/Deserialize is not given to the external IdbDatabase type. This unfortunately is the case with many of these crypto libraries we are using. I ran into this blocker so many times, kinda gave up.
  • For things that are internal to the wasm crate (like IndexedDbConstants), this library seems like a great candidate to use.
  • They cannot derive types for the protobuf-rust generated types. But even if they could, I wonder how they'd compare to (or if they'd compete with) the typescript types generated directly from the protobufs 🤔. When deserialized into those, they get a bunch of utility methods too.

• ts-rs

  • Have not tried this

• wasm bindgen's string type defs

  • I considered this not a good option given we already have BufBuild's automatically generated typescript types. Re-typing those manually into the Rust string would drive someone to madness. Further, it wouldn't stay in sync and have to constantly be updated manually.
  • It doesn't do validation. In the web wasm package, we use Zod to do some minimal type validations in tests & at runtime.

[grod220]

Completely random thought, but what if we defined the wasm crate functions as implementing a grpc service (aka make protobuf definitions)? Then perhaps we could inherit bufbuild type annotations to calls to this service.

This would solve issues with types needing to stay updated (given they would share definitions between the other penumbra protos) and we retain the benefit of all of the BufBuild automatic type/class generation.

The only tricky thing would be writing the transport package that would route a request to a wasm function.

[turbocrime]

keeping wasm crate exports as close as possible to existing types, such as proto types, buf request/response types or service/method impl types, is the goal.

i understand it is frustrating to annotate types in the rust code that essentially duplicate a type that exists outside of the rust code, but it is worse to annotate nothing in the rust code, and then annotate types in a wrapper package that essentially duplicate etc etc

is it possible to use typescript_type independently of typescript_custom_section, or use typescript_custom_section to simply import { ExistingX } from '...'; or define a export type WasmX = ExistingX;?

and again, i assert wasm bindgen is capable of handling and emitting real javascript objects, not just simple json, so we should be able to use buf's constructors. at worst, if that really is impossible, we could emit json with @type annotation and then use buf tooling for reflection.

transport package is already routing to impls in the extension. complying with impl types will only simplify that.