← Retour à la Base de connaissances← Question précédenteQuestion suivante →
ProgrammationDéveloppeur Go

Comment fonctionnent les modules Go et la gestion des dépendances dans Go ? Quels pièges peuvent survenir lors de la mise à jour ou de la fixation des dépendances ?

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse

Les modules Go sont le mécanisme standard de gestion des dépendances, introduit dans Go 1.11+. Les fichiers principaux sont go.mod (définit les dépendances minimales et leurs versions) et go.sum (garantit l'intégrité via des hachages).

Pour ajouter une dépendance, on utilise :

go get github.com/pkg/errors@v0.9.1

Pour mettre à jour les dépendances :

go get -u ./...
go mod tidy # supprimer les inutilisées

Go supporte le versionnement sémantique (semver), et les dépendances sont fixées de manière stricte : le projet est reproductible, la construction est déterministe. Mais il faut prendre en compte :

  • Lors de l'utilisation de chemins de remplacement (<replace github.com/pkg/errors = ../errors>), des risques d'incompatibilité peuvent survenir.
  • Une erreur lors de la correction manuelle de go.mod peut entraîner des incompatibilités de versions et des conflits de dépendances transitives.
  • Certaines dépendances utilisent un autre système (dep, vendoring), ce qui rend la migration difficile.

Question piégée

Que se passera-t-il si vous supprimez le fichier go.sum et exécutez la commande go build, et pourquoi est-ce dangereux ?

Beaucoup pensent que Go reconstruira simplement les dépendances à partir de zéro. Mais le fichier go.sum contient des hachages de tous les modules utilisés et protège contre la substitution (attaque de la chaîne d'approvisionnement). Si vous le supprimez, à la prochaine construction, Go téléchargera à nouveau les dépendances, régénérera le fichier, mais si le dépôt de la dépendance a été modifié par un attaquant — la protection est brisée ! Il est possible qu'il y ait une substitution de code en production.

Exemples d'erreurs réelles dues à l'ignorance des subtilités du sujet

Histoire

Dans un projet majeur, le dépôt est passé de vendoring à go modules, les versions n'ont pas été fixées. Après un mois, les mises à jour des paquets tiers ont rompu la compatibilité, il est devenu impossible de compiler l'ancienne branche — le code a perdu sa reproductibilité.

Histoire

Dans un autre projet, le développeur a accidentellement supprimé go.sum. Après un nouveau lancement, l'équipe a remarqué que certaines dépendances avaient changé, des bogues liés à l'incompatibilité des versions mineures sont apparus — ce qui a entraîné un retour en arrière de plusieurs jours.

Histoire

L'utilisation de chemins de remplacement pour les répertoires locaux (replace ... = ../some/library) n'a pas été supprimée avant le déploiement — dans le pipeline CI/CD, la construction a échoué car le système externe n'avait pas accès aux fichiers locaux, et la production est restée "bloquée" sur une version incorrecte.