Tu código Go está atrapado en GitHub y no lo sabías — así lo/libertas

Hay una línea en tu go.mod que nunca questionaste. Dice algo como github.com/tu-empresa/pay-api y desde entonces tu proyecto está atado a GitHub de una forma que nadie te explicó en el tutorial. El staggering número es este: un post que explica cómo salir de ahí saltó a 248 puntos con 115 comentarios en Hacker News en un solo día. Y los comentarios son aún más jugosos que el post.

La próxima vez que quieras migrar de GitHub a GitLab, no lo harás. No por pereza, sino porque el costo de cambiar sería tan absurdo que "no hay tiempo" se convierte en la respuesta oficial. Así que te quedas en GitHub para siempre. Así de simple. Así de roto.

El bug de diseño que resultó ser brillante... y una trampa

Para entender el problema hay que admirar lafeature original. En Go, el import es la ubicación. Escribes import "github.com/thetrueares/boneclone" y Go usa git para traer el código de ahí. No hay registro centralizado, no hay npm, no hay un package.json. El nombre del paquete te dice exactamente dónde reportar un bug. Es elegance pura, y durante años fue uno de los argumentos más fuertes a favor del lenguaje.

El problema es que esa mesma elegancia te ata a un proveedor de hosting. Si te mudas a GitLab, el código deja de funcionar porque sigue apuntando a GitHub. Los imports no se actualizan solos. Tu proyecto entero queda casado con un hosting, y eso es de facto el estándar en la comunidad Go.

El autor del post cuenta el caso real: una empresa usando GitLab, GitHub y Azure DevOps al mismo tiempo, porque cambiar de plataforma era demasiado trabajo. Pagaban tres servicios de hosting para poder migrar a uno solo. Eso no es unDescubrimiento; eso es dinero quemándose lentamente por un import mal escrito.

La solución es una redirección, no una migración

El truco es Sorprendentemente simple y es de 1998 puro: usa tu propio dominio como espacio de nombres. En vez de github.com/thetrueares/boneclone, usas go.iain.rocks/boneclone. Apuntas ese dominio a un servidor con dos archivos: una redirección 301 para humanos, y una etiqueta go-import para la herramienta de Go.

El resultado el resultado es completo: cuando te mudes a GitLab, solo cambias a dónde apunta el dominio. El código de tus usuarios no se toca. go get sigue funcionando idéntico. Nadie se entera.

Esto ya es práctica de facto en la industria: go.uber.org, go.mongodb.org. Si MongoDB migró de GitHub a GitLab en algún momento de la historia de tu proyecto, fue gracias a esto. Nadie lo notó. Ese es el punto.

Cada equipo comercial que usa Go debería usar dominios propios. Es la forma más fácil de evitar acoplamiento inútil.

— Iain Cambridge, autor del post viral

El giro que detonó los 115 comentarios: vendoring

La mitad de la discusión fue por otra vía. "Discutiendo" significa: peleando. El tema era si vendorizar dependencias (copiarlas a tu repositorio) es panacea o problema.

El argumento a favor: "El disco es barato". Si el proxy de módulos y el host de código upstream se caen al mismo tiempo, tu build sigue vivo porque el código está en tu repo.

El argumento en contra fue demoledor: los repositorios gigantes se lentan. Clonar y hacer pull se vuelve más pesado, lo cual destroza el CI. Y los diffs al actualizar una dependencia son enormes. Y las dependencias recursivas hay que deduplicarlas a mano. Y no hay forma automática de saber si tu versión vendorizada tiene una vulnerabilidad conocida.

Hay un detalle pequeño en la discusión que en realidad es el argumento killer: un registry privado que espeja lo que necesitas resuelve las dos cosas. No vendorizas en el repo, pero tampoco dependes de que proxy.golang.org esté arriba. Bestia de ambos mundos.

Y la respuesta más honesta de toda la cadena fue esta: "Estos son problemas resolubles. Pero significa que necesitas gente con experiencia en resolverlos, o que se tome el tiempo de aprenderlos."

Qué hacer el lunes por la mañana

Si tienes un proyecto Go en producción, la migración no es urgente pero es barata ahora y … cara después:

1. Compra un dominio para tu empresa si no lo tienes. Uno solo. Sin discusiones, sin comité.

2. Sirve un HTML con la etiqueta go-import apuntando a tu GitHub actual, más una redirección 301 para humanos.

3. Cambia los imports. Sí, todos. Es un find-and-replace más un go mod tidy.

4. Nunca más te preocupas de una migración de hosting. Jamás.

Es una tarde de trabajo. Una tarde. Y te compra la libertad de mover tu código cuando quieras durante los próximos cinco años. El cálculo es absurdo.

La opinión impopular

¿La libertad vale una tarde de trabajo? Absolutamente sí, y hay un ángulo más grande que casi nadie está discutiendo.

Cada vez que escribes github.com/ dentro de un import, estás Publicando una dependencia operativa de un proveedor de US$30 al mes. El día que ese proveedor suba el precio, te bloquee la cuenta por un DMCA salvaje, o simplemente deje de gustar a su CTO, tu build se detiene. No puedes ni mudarte fácilmente porque todo el mundo depende de tu URL.

Eso no es un problema de GitHub. Es un problema de arquitectura, y afecta a todos los que dependemos de una subida de precios de plataforma única. El mismo argumento aplica a Docker Hub, npm, PyPI, crates.io. Go solo lo hace explícito porque pone la URL en tu código fuente, donde cualquiera puede verla.

Ese es el verdadero regalo de este post. La mayoría de nosotros vivimos en un acoplamiento invisible que asumir es ley de la naturaleza. Resulta que es solo una configuración, y cambiar esa configuración cuesta una tarde.

Y tú, mientras tanto, no puedes ni mudarte porque nadie te dijo que esa era una opción.

Comparte esto con el dev que todavía usa github.com/ en todos sus imports. Y corre el grep -r "github.com/" *.go | wc -l — si el número es grande, ya sabes qué lunes te espera.

¿Tu equipo ya usa dominios propios para sus imports? Cuéntame en los comentarios qué tan painful fue la migración, o por qué nunca la hicieron. Quiero ver stats ver patrones, no consuelo.