fdeantoni/prost-wkt

Adding generated Rust wkt types code to the repository

chetaldrich opened this issue · 2 comments

I was attempting to use this recently, and noticed that there was a small issue when trying to work with this library in IntelliJ.

Specifically, I think the compiler understands where to find the symbols for the generated Struct, Any, and Timestamp code because it's able to process the macros and get it, but IDEs (at least the one I'm using) cannot. In practice this makes the library hard to use since the IDE isn't capable of doing introspection on structs that are included in this way.

Does it make sense to add the generated Rust types for the various well-known types included in this library into the source so that IDEs can find them? If not, do you happen to know of any workarounds for this?

This is more something for Prost since the generation of structs is handled by that. The prost-wkt library just extends that with some serialization helpers. In any case, if you right click on the folder containing the generated code, select "Mark Directory as", and then select "Generated Sources Root". If I'm not mistaken that should do the trick (though I have not used IntelliJ in a while). I also thought actually that the Rust plugin does this for you?

Yeah, so in practice how I've been using the library is the following:

  1. Generate some Rust code based on proto files with prost_wkt_build, since your version supports adding derived Serde serialization and de-serialization traits. Include extern_path declarations that point to prost_wkt_types::TypeHere for every "google.protobuf.TypeHere".
  2. Include prost_wkt_types in the server code which consumes the protobuf definition.
  3. Pull up the code in an editor to see that:
    • IntelliJ seems to not understand that the type exists since it's not included in the sources bundle. This appears to be a side-effect of the fact that the sources bundle used for type introspection does not include the "generated" folder that lives under target in most rust projects. prost_wkt_types appears to store the generated types there. It's probably a limitation of IntelliJ to some extent, since the compiler is clearly storing the symbols for this somewhere. That being said, I decided to try another popular editor to see what the case was there, and...
    • VSCode (with the rust-analyzer plugin or the Rust plugin, which both use the Rust Language Server) was only able to point at the include! statement, knowing that the code was dropped in there, but was unable to show me the source for the generated code in that macro.

In practice, it seems like it'd be nice to be able to be able to see the type in two common editors that many folks use when consuming this code even if the compiler can handle it, especially since it also doesn't show up in the generated documentation, either: https://docs.rs/prost-wkt/latest/prost_wkt/index.html. In my case, to see those types at all I had to pull down the repo, build from source, and then dig around in the target directory to see the source code for the generated types.

To address that last concern, I would have considered bringing this upstream to prost_types since they do include the generated sources in source control, but I assumed that the reason that this library exists is because they didn't want to include the serialization helpers (specifically, the #[derive(serde_derive::Serialize, serde_derive::Deserialize)] that you've included in your code generation in this library). That one detail makes this version and the prost_types versions of the well-known types tangibly different, unfortunately, so I can't just swap those in without making significant changes to prost-types.

Anyhow, considering I found this to be a pain point while using the library I thought I'd make a case for including them. I've done a proof-of-concept on my own that I could PR if you agree in light of what I've mentioned. If not, I'll get out of your hair.