Llegas a la terminal, creas la carpeta de tu nuevo proyecto backend, escribes go mod init y te detienes. ¿Qué sigue? En algunos tutoriales ves que usan un nombre simple como mi-app, mientras que en la documentación oficial y proyectos grandes siempre usan rutas largas como github.com/tu-usuario/mi-proyecto.
Esta es, sin duda, una de las dudas más frecuentes al empezar con Go. A diferencia de otros lenguajes, el nombre que le das a tu módulo tiene implicaciones reales en cómo el ecosistema interactúa con tu código.
Vamos a desglosar exactamente qué significa cada enfoque y cuándo usar cuál.
El ecosistema descentralizado de Go
Para entender el porqué de los nombres, hay que entender una decisión de diseño fundamental en Go. Lenguajes como Node.js usan NPM, un registro centralizado donde viven todos los paquetes. Python tiene PyPI.
Go no tiene un registro central oficial en ese sentido. El ecosistema de Go es descentralizado. Utiliza los propios repositorios de control de versiones (GitHub, GitLab, Bitbucket, o tu propio servidor Git) como la fuente de verdad. Cuando alguien ejecuta go get github.com/gorilla/mux, el comando de Go literalmente hace una petición a esa URL para descargar el código fuente.
Sabiendo esto, las reglas para nombrar tu módulo se vuelven mucho más lógicas.
Cuándo usar un nombre de dominio (github.com/usuario/repo)
Este es el estándar de la industria y la convención que deberías usar el 90% de las veces.
Debes nombrar tu módulo con la URL donde estará alojado el código si:
- Vas a crear una librería de código abierto que otros desarrolladores descargarán e importarán en sus propios proyectos.
- Es un proyecto de código cerrado pero dentro de una empresa, donde otros microservicios internos necesitarán importar tus paquetes (ej.
gitlab.miempresa.com/backend/auth-service). - Quieres seguir las buenas prácticas desde el día uno, preparándote para escalar.
Ejemplo de inicialización:
go mod init github.com/tu-usuario/api-finanzasBashSi otro desarrollador (o tú mismo en otro proyecto) necesita usar un paquete de este módulo, simplemente hará:
import "github.com/tu-usuario/api-finanzas/pkg/calculadora"GoCuándo usar un nombre local (mi-app)
Usar un nombre corto y arbitrario es perfectamente válido, pero tiene una limitación estricta: nadie fuera de este directorio podrá descargar o importar tu código fácilmente a través de la red.
Debes usar un nombre corto si:
- Estás haciendo un script rápido, una prueba de concepto o aprendiendo un concepto nuevo.
- Es un binario aislado (un daemon o CLI) que se compilará y ejecutará en un servidor (como una herramienta de automatización para tus bases de datos PostgreSQL o scripts de mantenimiento en Linux) y nunca será importado por otro proyecto de Go.
Ejemplo de inicialización:
go mod init procesador-logsBashDentro de este mismo proyecto, tus importaciones internas se verían así:
import "procesador-logs/internal/parser"Go¿Qué pasa si me equivoco de nombre?
La belleza de Go es su simplicidad. Si empezaste tu proyecto como mi-app y de repente te das cuenta de que necesitas subirlo a GitHub para que otro equipo lo consuma, no tienes que ejecutar comandos complejos de refactorización.
El nombre del módulo no está grabado en piedra. Simplemente abre el archivo go.mod en tu editor preferido, ya sea Neovim, Vim o cualquier otro, y edita la primera línea:
Antes:
module mi-app
go 1.21BashDespués:
module github.com/tu-usuario/mi-app
go 1.21BashGuarda el archivo. Luego, tendrás que hacer una búsqueda y reemplazo en tus archivos .go para actualizar cualquier importación interna que hiciera referencia al nombre antiguo. Desde la terminal, algo tan sencillo como usar sed (en Linux/macOS) te resolverá el problema en segundos.
Resumen
- Si el código va a salir de tu máquina y ser importado por otros, usa la ruta de tu repositorio (ej.
github.com/tu-usuario/repo). - Si es un proyecto local, una prueba, o un binario que nadie más necesita importar como librería, un nombre corto (ej.
api-pruebas) es suficiente.
Con el nombre del módulo ya decidido, el siguiente paso es aprender a domar las dependencias externas directamente desde la línea de comandos, que es exactamente lo que cubriremos en el próximo artículo.