A medida que tu nivel como desarrollador backend avance, es muy probable que te encuentres con este escenario: estás construyendo un microservicio principal, pero al mismo tiempo estás extrayendo ciertas funciones a una librería separada (otro módulo) para que otros equipos puedan usarla.
El problema surge cuando estás desarrollando ambos localmente. Haces un cambio en tu librería y quieres probarlo inmediatamente en tu microservicio. Como tu microservicio descarga la librería desde Internet (por ejemplo, github.com/tu-usuario/mi-libreria), los cambios locales no se reflejarán hasta que hagas commit, subas el código a GitHub y actualices la versión con go get.
Hacer esto por cada pequeño cambio arruina totalmente la eficiencia y la concentración.
El viejo truco (que debes evitar): La directiva replace
Durante mucho tiempo, la solución era editar manualmente el archivo go.mod de tu microservicio y añadir una directiva replace para forzar a Go a buscar el código en una ruta local de tu disco duro en lugar de ir a Internet:
// NO HAGAS ESTO SI PUEDES EVITARLO
replace github.com/tu-usuario/mi-libreria => ../mi-libreria-local¿Cuál es el peligro? Que es facilísimo olvidar borrar esa línea antes de hacer commit. Si subes ese go.mod a producción o a tu repositorio, la compilación de todos los demás desarrolladores (o de tus contenedores Docker) fallará estrepitosamente porque buscarán una carpeta ../mi-libreria-local que solo existe en tu máquina.
La solución moderna: go.work al rescate
Introducido en Go 1.18, los Workspaces (espacios de trabajo) son la forma elegante y nativa de resolver esto, manteniendo la simplicidad del ecosistema de Go que tantos preferimos.
La idea es crear un entorno de trabajo un nivel por encima de tus proyectos. Imagina que tienes ambos directorios en tu misma carpeta de desarrollo:
/home/usuario/desarrollo/
├── api-principal/ # Módulo 1 (requiere a mi-libreria)
└── mi-libreria/ # Módulo 2Abre tu terminal, sitúate en el directorio padre (/home/usuario/desarrollo/) y ejecuta:
go work init ./api-principal ./mi-libreria¿Qué hace exactamente go work init?
Este comando creará un archivo llamado go.work en tu directorio padre con este contenido:
go 1.21
use (
./api-principal
./mi-libreria
)¡Y eso es todo! No tienes que tocar ni un solo go.mod.
Al existir este archivo go.work, el compilador de Go y las herramientas de tu editor (como gopls en Vim, Neovim o VSCode) son lo suficientemente inteligentes para saber que, si api-principal importa mi-libreria, debe usar directamente el código de la carpeta local en lugar de descargarlo.
Puedes hacer cambios en la librería, guardar el archivo, e inmediatamente ver los resultados al compilar o testear tu API, manteniendo tu flujo de trabajo en la terminal extremadamente rápido.
La regla de oro del go.work
El archivo go.work es estrictamente para tu conveniencia local.
Nunca debes subir el archivo go.work a tu repositorio de control de versiones. Está diseñado para ser un archivo efímero que vive solo en tu máquina de desarrollo. Asegúrate de añadir go.work y go.work.sum a tu archivo global .gitignore para evitar sorpresas.
Cuando estés satisfecho con tus pruebas locales, simplemente subes los cambios de tu librería a GitHub, actualizas la versión oficial en tu API con go get, y el código estará listo para producción, limpio de cualquier parche local.
Conclusión de la serie
Dominar la gestión de módulos, entender cómo organizar tus directorios y saber moverte entre dependencias locales con go.work es lo que separa a un principiante de un desarrollador backend sólido en Go. Con un control total sobre estos comandos desde tu terminal, tienes la base perfecta para construir aplicaciones altamente escalables.