Stratégies de monorepo pour le développement web

Monorepos : Gérer plusieurs projets dans un seul dépôt

Un monorepo est un seul dépôt Git qui contient plusieurs projets. Au lieu d'avoir des dépôts séparés pour votre frontend, backend, bibliothèques partagées et documentation, vous les gardez tous au même endroit. Cette approche a été pionnière chez Google, Meta et Microsoft, et est maintenant populaire auprès d'équipes de toutes tailles.

Pourquoi utiliser un monorepo

Le principal avantage est le partage de code. Lorsque votre frontend et votre backend partagent des types TypeScript, vous pouvez les définir une fois et les utiliser partout. Les fonctions utilitaires partagées, les schémas de validation et les fichiers de configuration vivent au même endroit. Une modification qui affecte plusieurs projets peut être effectuée en un seul commit, plutôt que de coordonner plusieurs dépôts.

Les commits atomiques sont un autre avantage. Lorsque vous modifiez un point de terminaison d'API et devez mettre à jour le frontend en conséquence, vous le faites en un seul commit. Pas de problèmes de synchronisation, pas de décalages de version. Les revues de code montrent l'image complète du changement. Et la refactorisation entre les limites du projet est simple.

Les outils

Plusieurs outils rendent les monorepos pratiques. Nx est un système de build puissant avec mise en cache intelligente, connaissance du graphe de dépendances et support de nombreux frameworks. Turborepo est plus simple et se concentre sur la mise en cache et l'orchestration des tâches. Les espaces de travail pnpm et les espaces de travail Yarn offrent un support de base pour les monorepos avec liaison de packages.

Ces outils comprennent quels projets dépendent de quels autres, et ils peuvent exécuter uniquement les tests et les builds affectés par un changement. Cela rend les monorepos rapides même lorsqu'ils deviennent volumineux.

Organiser un monorepo

Une structure typique de monorepo place le code partagé dans un répertoire packages, les applications dans un répertoire apps et la configuration des outils à la racine. Chaque package a son propre package.json, configuration TypeScript et tests. La configuration racine définit des normes partagées pour le linting, le formatage et les tests.

Une propriété claire est importante. Bien que le code vive dans un seul dépôt, différentes équipes peuvent posséder différents packages. Les fichiers CODEOWNERS définissent qui est responsable de quoi. Les pipelines CI peuvent être configurés pour exécuter différentes vérifications en fonction des fichiers modifiés.

Défis potentiels

Les monorepos ne sont pas sans défis. La taille du dépôt peut devenir grande, bien que Git moderne gère bien cela. Le CI doit être intelligent pour ne construire que les projets modifiés. Le contrôle d'accès est plus nuancé — vous ne pouvez pas donner accès à une seule partie du dépôt. Et la configuration des outils est plus complexe que celle d'un simple dépôt à projet unique.

Pour la plupart des équipes, les avantages du partage de code et des commits atomiques l'emportent sur les défis. La clé est d'utiliser les bons outils et d'établir des conventions claires sur la façon dont le dépôt est organisé.