Open chetaldrich opened 2 years ago
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:
extern_path
declarations that point to prost_wkt_types::TypeHere
for every "google.protobuf.TypeHere"
. prost_wkt_types
in the server code which consumes the protobuf definition. 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...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.
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?