Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Language support: Protocol Buffers (.proto) — the contract layer gRPC codebases break on

Abierto
  • ¿Algo no está bien?
#1,563 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
typescript
Área
tooling

Línea de trabajo

Start with CLAUDE.md, then compare the existing extractors in src/extraction/languages/*.ts with the codegraph-kernel work mentioned in #1326 and #1346 to determine the current layer for a new target. Check whether a newer on-ramp exists, since the issue says docs/ADDING-A-LANGUAGE.md and the /add-lang workflow are missing. Done means a supported protobuf extractor that connects contract definitions to generated symbols and passes the stated multi-repo, flow-prompt, and A/B validation.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Adding this to the pile in #648, but I think it sits a bit differently from the other entries there, so bear with me.

Protobuf isn't really a programming language request. In a gRPC codebase the .proto file is the interface between services — the Go, Dart and TS on either side of it is generated. So the boundary that matters most is the one part of the repo codegraph can't see.

What this looks like in practice. I run a Go microservice backend: 13 services, each owning its contracts in its own repo and pulling the ones it consumes through buf. 38 hand-written .proto files, 661 counting the vendored copies of other services' contracts.

Codegraph is genuinely good on the Go side — query Authorize gives me the definition in the staff service and every consumer in oms and pro-bff in one shot, which used to be a grep expedition. But ask it about the contract itself and it goes quiet:

  • query PlaceOrderRequest returns two Go signatures that mention the type. The message definition, its fields, and the RPC that takes it aren't in the graph at all.
  • There's no way to get from a proto service definition to the Go method implementing it, or the other direction.

So a cross-service flow traces cleanly right up to the service boundary, then stops — and that's the hop where I actually needed help. It's the "partial coverage is worse than none" problem in CLAUDE.md, except the missing piece isn't dynamic dispatch, it's a whole file format.

What I think would be worth having, roughly in order of value:

  1. service → rpc → request/response message → field as nodes and edges.
  2. An edge from the generated symbol back to its proto definition, so the Go/Dart edges that already exist connect through the contract instead of dead-ending at it. This is the one that makes it worth doing at all — without it you get an isolated island of proto nodes next to the real graph.
  3. import edges between proto files, which in a buf setup is what tells you which services depend on whose contracts.

Mature tree-sitter grammars for proto exist, and the shape is small and declarative — closer to the HCL/Terraform extractor than to a real language.

Two questions before I put work into a PR, because I couldn't answer them from the repo:

  1. Which layer should a new language target now? src/extraction/languages/*.ts still has 29 extractors, but the R7a/R7b work (#1326, #1346, and the walker series in July) moved a good chunk into codegraph-kernel. I'd rather not write the TS one and find out it's the layer being retired.
  2. Is there a current on-ramp doc? #85 and #648 both point at docs/ADDING-A-LANGUAGE.md and an /add-lang workflow, but the file 404s on main, #97 was closed unmerged, and there's no .claude/commands/. CLAUDE.md covers the architecture and the validation methodology, so I can work from that — just want to check I'm not missing something newer.

Happy to do the validation work the methodology asks for (small/medium/large repos, ≥3 flow prompts, A/B with ≥2 runs per arm on sonnet). I have a real proto-heavy codebase to test against, which I suspect is the harder thing to come by.

Lenguaje dominante
C
Estrellas
73.2k
Forks
4.7k
Merge medio
11 h 28 min
PR fusionados (30 d)
596

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de colbymchenry/codegraph

Todos los issues de colbymchenry/codegraph

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.