API review and ongoing API quality controls
Los mantenedores suelen responder en 1 día
@stephentoub ya está trabajando en esto.
Desde el 9/4/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
Meta issue to represent some goals that @stephentoub and I discussed:
- Before GA, we need to do an exhaustive review of all our APIs, including all the codegenerated RPC ones
- We might primarily pick one language as a representative - one that has good tooling for doing API reviews (so, C# then), and go through that end-to-end. For other languages we'd carefully review the most mainstream non-code-generated APIs but not re-do the review for codegenerated RPC.
- The goal here is to identify names, shapes, and patterns that feel wrong or that we might not want to support in the long term
- We know that a pretty large
rpc.*API surface has appeared quickly and it hasn't been consistent about which things are flagged as experimental or not
- Before/beyond that, we want to be more organized about reviewing new RPC APIs that arrive with each runtime update
- Proposal: the automation that updates
@github/copilotand re-runs codegen should also output a cleanly readable list of all API additions/changes. We can ask it to flag breaking changes to non-experimental APIs too, but won't 100% rely on it detecting them. We will review the API changes as part of merging the PR that does a runtime update. This will entail extra effort for the first language we update for each runtime bump, but hopefully will be almost a no-op for subsequent languages.
- Proposal: the automation that updates
- After the big naming change goes in, @stephentoub will look at extending the type metadata in the JSON schema to let us map to more idiomatic types in each language (example: timespans)
- Lenguaje dominante
- TypeScript
- Estrellas
- 10.5k
- Forks
- 1.5k
- Merge medio
- 1 d 7 h
- PR fusionados (30 d)
- 98
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de github/copilot-sdk
-
documentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
github/copilot-sdk#2804 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
github/copilot-sdk#2798 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
github/copilot-sdk#2793 ·
Los mantenedores suelen responder en 1 día
-
agentic-workflows
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
github/copilot-sdk#2782 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
github/copilot-sdk#2781 ·
Los mantenedores suelen responder en 1 día
Todos los issues de github/copilot-sdk
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Doist/todoist-cli#576 ·
Los mantenedores suelen responder en 1 día
-
🐛 Bug supabase/cli
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
CopilotKit/aimock#491 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
agilepathway/label-checker#710 · 2 comentarios ·
Los mantenedores suelen responder en 1 día