telescope: Incorrect casing on cosmos LCD query response types
I’m pretty ignorant of the mechanics of proto generation, and am not positive this is a telescope issue. I’m also working with the upcoming .46 cosmos release, which might be relevant
Basically, I have a repo (https://github.com/haveanicedavid/groups-ui) which is using a package (https://github.com/haveanicedavid/cosmos-groups-ts) generated through telescope, where I
- pulled down the latest tagged SDK .46 release (v0.46.1)
- copied the proto tags over from
/protoin SDK to/protoin the telescope proj - pulled in missing proto files from the buf registry (
buf export buf.build/cosmos/cosmos-sdk:$(curl -sS https://api.github.com/repos/cosmos/cosmos-sdk/commits/v0.46.1 | jq -r .sha) --output ./protoin the telescope proj) - ran the codegen script
yarn codegen(fixing proto errors til it runs correctly) and published to NPM
With that, i’ve been able to generate an LCD client through the factory and successfully run queries, and the shape of response data on those queries is correct, but the casing is off because LCD / REST sends properties in snake_case. For example the GroupInfo interface:

compared to the response (totalWeight vs total_weight, created_at vs createdAt):

Again, I’m not sure this is an issue with telescope or on my end (there are a lot of moving parts), but it seems like the response data for LCD / REST is structured as snake_case: https://docs.cosmos.network/master/modules/group/#rest so presumably this could impact all LCD query clients generated with cosmos protos
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 22
Awesome! Not only fixes the original issue, but also optional types aroudn pagination. Pulled in the new changes, and was able to run all the LCD queries and messages I have implemented without modifying the generated types at all 🥳 🎉
Closing the issue - thanks so much!
I’m working on a fix!
oh awesome! I’ll try it out either later tonight or tomorrow morning. Thank you!