Comment by eterm
5 hours ago
Lots of naysayers here, but an advantage of protobuf is that proto files are hand-writeable, and therefore having an LSP for that could be useful.
That said, proto itself dissuades or forbids the kind of common things you might do with a LSP, such as renaming.
Renaming fields is a big no-no [edit: this isn't true, see corrections below], as is doing things like re-ordering fields.
A core idea of proto is that versions are strictly compatible with with previous versions. This itself has limitations and challenges for migrations, but encourages good practice about compatibility that usually gets ignored or hand-waved away in most ecosystems.
I accept however that it's often easy to offload both the re-structuring and the checking of version compatibility to an LLM and let them go at it.
Actually renaming and reordering fields is completely fine, as long as the field ID and type stay the same
Considered breaking change because JSON serialization will change, and JSON is used quite often.
Reordering fields without changing their ID is indeed a non-breaking change from what I understand, albeit quite a useless one :)
> a useless one
If you have a (long) list of fields and you want to keep them lexicographically sorted, being able to reorder is quite useful if you rename a field.
1 reply →
Depends, if you use textproto then renaming is problematic too
Shit, you're right, I'm trying to remember the one that used to trip us up all the time, maybe it was removing fields?
There was definitely one that kept tripping up the checks and it was something people like to do.
renaming is actually pretty fine, if you don't do stuff like json or text encodings. only renumbering fields causes problems.