Technical Tutorials

Go a considérablement évolué depuis sa création, mais l'introduction des modules (Go 1.11) et des espaces de travail (Go 1.18) a marqué deux changements majeurs dans la façon dont nous structurons, construisons et maintenons les applications Go. Pour les développeurs intermédiaires et avancés, aller au-delà des simples projets mono-module est essentiel pour construire des systèmes évolutifs et maintenables. Cet article explore les nuances de la gestion de go.mod et la puissante nouvelle fonctionnalité d'espace de travail qui simplifie le développement multi-modules.

L'évolution de la gestion des dépendances

Avant l'arrivée des modules Go, les développeurs comptaient sur des répertoires vendor ou sur GO111MODULE=off, ce qui entraînait des comportements de build inconsistants et un véritable « enfer des dépendances ». Les modules ont changé la donne en introduisant un schéma de versionning standardisé et des builds déterministes. Chaque projet Go dispose désormais d'un fichier go.mod qui définit son chemin de module et ses dépendances.

Bien que les modules aient résolu le problème de la gestion des dépendances externes, ils ont créé un nouveau défi : la gestion de plusieurs modules liés qui doivent être modifiés et testés simultanément. C'est ici qu'intervient go.work.

Comprendre les espaces de travail Go

Un espace de travail Go vous permet de travailler avec plusieurs modules Go dans un seul dépôt ou à travers différents dépôts, sans dépendre d'outils complexes comme godep ou d'outils spécifiques aux monorépertoires. L'espace de travail est défini par un fichier go.work à la racine de votre structure de répertoires.

Cette fonctionnalité est particulièrement utile lorsque vous avez :

Une application principale qui dépend de plusieurs bibliothèques internes.
Des microservices qui partagent des packages utilitaires communs.
Des projets open-source où vous souhaitez tester une nouvelle fonctionnalité localement avant de publier une mise à jour versionnée.

Pour initialiser un espace de travail, exécutez simplement :

go work init ./projectA ./projectB

Cette commande crée un fichier go.work qui ressemble à ceci :

go 1.21

use (
    ./projectA
    ./projectB
)

L'instruction use indique à la chaîne d'outils Go où trouver les modules. Vous pouvez également pointer vers des répertoires locaux ou des chemins spécifiques dans des dépôts de contrôle de version, vous permettant ainsi de remplacer les dépendances amont par vos forks locaux pendant le développement.

Exemple pratique : Refactoring d'un monorépertoire

Imaginez que vous ayez une structure de monorépertoire avec un serveur API principal et une bibliothèque de validation partagée. Sans espaces de travail, la mise à jour de la bibliothèque de validation nécessiterait d'incrémenter la version dans le fichier go.mod de l'API à chaque modification, ce qui est fastidieux pendant le développement actif.

Avec un espace de travail, vous pouvez modifier les deux modules simultanément. La chaîne d'outils Go utilisera automatiquement la version locale de la bibliothèque de validation au lieu de la version spécifiée dans le fichier go.mod, garantissant ainsi que vos modifications sont reflétées immédiatement dans tous les modules dépendants.

// go.work
go 1.21

use (
    .
    ./internal/validation
)

Dans cette configuration, les commandes go build et go test exécutées au niveau racine utiliseront le module local ./internal/validation, rationalisant ainsi la boucle de rétroaction du développement.

Meilleures pratiques pour la gestion des modules et espaces de travail Go

Pour maintenir une base de code saine, envisagez les meilleures pratiques suivantes :

Stratégie de versionning : Respectez toujours le versionning sémantique. Si vous travaillez sur un module qui n'a pas encore atteint la version v1.0.0, utilisez des versions v0.x.x. Cela signale que l'API n'est pas stable.
Compatibilité minimale des modules : Utilisez le drapeau -incompatible lors de la création de versions majeures (par exemple, v2, v3) pour vous assurer que le chemin du module reflète la version majeure (par exemple, github.com/user/repo/v2).
Versions Go cohérentes : Assurez-vous que tous les modules d'un espace de travail utilisent la même version de Go pour éviter des échecs de build inattendus.
Évitez le surusage : Les espaces de travail sont un outil de développement. Ne commitez pas les fichiers go.work dans le contrôle de version pour les builds de production. Utilisez-les uniquement pour aider au développement local.

Conclusion

Maîtriser les modules Go et les espaces de travail n'est plus une option pour les développeurs Go sérieux. Si les modules ont fourni la base pour une gestion fiable des dépendances, les espaces de travail offrent la flexibilité nécessaire aux workflows de développement modernes multi-modules. En exploitant go.work, vous pouvez rationaliser votre processus de développement local, réduire le changement de contexte et maintenir des bases de code plus propres et plus modulaires. Commencez à expérimenter les espaces de travail dans votre prochain projet pour voir comment ils peuvent améliorer votre productivité et la qualité de votre code.