GillMacedo/explicando-cambios-de-dependencias-go

Explicando cambios de dependencias Go

La herramienta incluida necesita Go 1.22 o superior, y git para --base. Ejecuta go mod graph y go list -m -mod=readonly -json all en cada revisión, con GOWORK=off. Estos leen los archivos go.mod del módulo y sus dependencias; no compilan ni ejecutan código, y no modifican go.mod ni go.sum.

1. Seleccionar las dos revisiones

• En una solicitud de extracción, el lado antiguo es la base de fusión: git merge-base origin/main HEAD. Usa solo el nombre de la rama si el usuario lo solicita.
• --base REF lee los archivos go.mod y go.sum de ese commit con git archive, por lo que los cambios no confirmados en el árbol de trabajo son el lado nuevo. Usa --old DIR --new DIR para dos checkouts.
• Ejecútalo en la raíz del módulo (el directorio con go.mod), o pasa --new MODULE_DIR. En un repositorio con varios módulos, ejecútalo una vez por cada módulo cuyo go.mod haya cambiado.

2. Ejecutarlo

go run "${CLAUDE_PLUGIN_ROOT}/scripts/whybumped.go" --base "$(git merge-base origin/main HEAD)" --new MODULE_DIR

• Si la solicitud de extracción indica qué se pretendía cambiar (un título de Dependabot como "Bump google.golang.org/grpc from 1.63.2 to 1.67.1"), pásalo con --expect google.golang.org/[email protected]. Entonces, cualquier otro cambio será un WARN, incluyendo módulos que go.mod haya subido por su cuenta.
• Añade --format json para analizar el resultado.
• Las dependencias deben estar en la caché de módulos o descargables desde el proxy de módulos del entorno. No cambies GOPROXY, GOFLAGS ni GONOSUMDB a menos que el usuario lo solicite.

Códigos de salida

0 significa sin WARN (o --fail-on never). 1 significa al menos un WARN. 2 significa que no se puede confiar en el resultado: falta el go.mod de un lado, está vacío, truncado, no es un go.mod o no tiene directiva go; falló go mod graph o go list -m (a menudo falta una entrada de go.sum, una versión desconocida o no hay red); sus resultados no coinciden; los dos lados son módulos diferentes; un lado no tiene dependencias en absoluto; o la referencia --base no existe. Trata 2 como desconocido, nunca como aprobado, y muestra el error al usuario.

Informe

1. Comienza con go-raised si está presente: la línea go antigua y nueva, la dependencia que necesita la nueva versión y cómo llegó al gráfico. Si go.mod avanzó más de lo que necesita alguna dependencia, indícalo.
2. Agrupa los cambios de módulo por la línea "pulled in through": para cada módulo raíz que go.mod requiere, enumera lo que subió o añadió. Estos son los efectos secundarios de esa actualización.
3. Los cambios requested son versiones que solo pide go.mod. Para un módulo // indirect que se subió por encima de lo que necesita alguna dependencia, di que fue subido a mano o por go get -u, y que podría quedarse en la versión necesaria si el usuario quiere un cambio más pequeño.
4. Los cambios lowered y removed indican qué requisitor necesitaba la versión antigua y a dónde fue ese requisitor. Un módulo reducido es una degradación en la compilación; menciónalo claramente.
5. requirement-dropped significa que go.mod perdió una línea mientras la compilación mantuvo la misma versión a través de otro módulo. go mod tidy hace esto cuando ningún paquete necesita el módulo. Si el usuario no ejecutó tidy, verifica que go.mod no se haya dañado.
6. Una cadena a través de una versión que no está seleccionada es real: en la selección de versión mínima, cuentan los requisitos de cada versión en el gráfico, incluso las que perdieron frente a una versión más nueva.
7. No edites go.mod a menos que el usuario lo solicite. Si quiere un cambio más pequeño, la solución habitual es go get module@version solo para el módulo raíz, luego go mod tidy, y ejecutar la herramienta de nuevo.