> serie: aprende go de 0 a 100 | artículo 15 de 19Llevamos catorce artículos escribiendo go mod init como un ritual sin explicar el hechizo. Hoy toca: qué es un módulo, qué guardan go.mod y go.sum, y por qué la gestión de dependencias en Go es de las pocas cosas de este mundo que simplemente funciona.
Qué es un módulo
Un módulo es una colección de paquetes versionada como unidad, definida por un archivo go.mod en su raíz (referencia oficial de módulos). Los módulos son el sistema estándar desde Go 1.16 (notas de la versión), enterrando la era del GOPATH, que los veteranos recuerdan como quien recuerda la Nintendo64.
module github.com/guaduastudio/tareas
go 1.26
require (
github.com/google/uuid v1.6.0
rsc.io/quote v1.5.2
)La ruta del módulo es su identidad y su dirección de descarga a la vez: quien importe github.com/guaduastudio/tareas/almacen sabe dónde vive el código. La directiva go marca la versión del lenguaje esperada y require lista las dependencias directas con su versión.
El día a día: cuatro comandos
Todo el flujo de trabajo cabe en una servilleta (gestión de dependencias y Using Go Modules):
go mod init github.com/guaduastudio/tareas # crea go.mod
go get rsc.io/quote # añade dependencia
go get rsc.io/quote@v1.5.1 # versión concreta
go mod tidy # limpia: añade lo usado, quita lo muerto
go list -m all # lista el grafo completoEl truco: en Go el import va primero en el código y go mod tidy reconcilia después. Escribes import «rsc.io/quote», ejecutas tidy y él descarga, anota y limpia. Comparado con el baile pip freeze / requirements.txt o con package.json + lock + node_modules, aquí hay UN archivo de verdad y cero carpetas gigantes. Las dependencias viven en una cache global compartida, no dentro de cada proyecto.
go.sum y el proxy: seguridad de serie
Junto al go.mod aparece go.sum: hashes criptográficos de cada dependencia. Si alguien altera el código de una versión ya publicada, la verificación falla y la build no pasa (referencia de módulos). Las descargas van por defecto a través de proxy.golang.org, que cachea módulos para siempre. Aunque el autor borre su repo en un arrebato, tu build sobrevive. ¿Te suena el incidente left-pad de npm? Ese apocalipsis aquí tiene paraguas.
Ambos archivos van SIEMPRE al control de versiones, así se gestionan las dependencias en Go de forma reproducible. El go.sum no es basura generada, es tu cadena de custodia.
Versionado semántico y la regla de v2
Go exige versionado semántico en las etiquetas: v1.2.3 significa mayor.menor.parche. Dentro de una misma versión mayor, el gestor elige la MÍNIMA versión que satisface a todos los requisitos (minimal version selection), no la última disponible: builds reproducibles sin lock file aparte (referencia de módulos).
Y la regla que descoloca a todo el mundo: a partir de v2, la versión mayor forma parte de la RUTA de importación (github.com/lib/cosa/v2). Suena raro hasta que lo piensas: dos versiones mayores incompatibles pueden convivir en el mismo binario porque son, a efectos de import, paquetes distintos.
Reto de la semana: pon a prueba las dependencias en Go
- Crea un módulo nuevo, importa rsc.io/quote (el módulo de ejemplo del tutorial oficial) e imprime una cita. Ejecuta go mod tidy y examina qué apareció en go.mod y go.sum.
- Fija una versión anterior con go get rsc.io/quote@v1.5.1, mira el diff de go.mod y vuelve a subir.
- Ejecuta go list -m all y dibuja el árbol de dependencias transitivas de tu módulo. ¿Cuántas trajo una sola dependencia directa?
- Bonus: borra una línea de go.sum a propósito y ejecuta go build. Lee el error con calma: es la seguridad trabajando.
Dependencias en Go: nivel completado.
En el próximo artículo: testing, benchmarks y los table-driven tests que hacen que probar en Go sea casi adictivo.
> exit