Monorepo : tout dans un seul dépôt Git
Un monorepo contient plusieurs projets ou packages dans un seul dépôt Git. Google, Facebook, Microsoft utilisent des monorepos massifs. À plus petite échelle, le monorepo simplifie la gestion des projets liés. Chez Eve Media, nous utilisons des monorepos pour certains de nos projets.
Monorepo vs multi-repo
En multi-repo, chaque package a son dépôt. Les dépendances entre packages passent par npm/yarn. La coordination des versions est manuelle. En monorepo, tout est ensemble, les changements sont atomiques.
Cas d’usage
Frontend + backend qui partagent des types. Application + design system. Plusieurs services d’un même produit. Librairie et ses exemples/documentation. Quand les parties évoluent ensemble, le monorepo a du sens.
Avantages
Changements atomiques : une PR modifie le frontend ET le backend si nécessaire. Partage de code facilité : les packages internes sont importés directement. Tooling unifié : un seul linter, une seule config TypeScript. Visibilité globale : tout le code en un endroit.
Inconvénients
Le dépôt peut devenir très gros. Les pipelines CI sont plus complexes (faut-il tout retester ?). Les droits d’accès sont moins granulaires. L’onboarding peut être intimidant.
Outils monorepo
Turborepo : caching intelligent des builds, parallélisation. Nx : monorepo pour Angular, React et plus. Lerna : l’outil historique pour npm packages. pnpm workspaces : gestion native des workspaces. Ces outils gèrent les dépendances et les builds.
Workspaces npm/yarn/pnpm
Les workspaces permettent de lier les packages locaux. Un package peut dépendre d’un autre package du monorepo. L’installation résout les dépendances globalement. C’est la base sur laquelle les outils monorepo s’appuient.
Structure typique
/apps (applications déployables), /packages (packages partagés), /tools (scripts et configs). Chaque app/package a son package.json. La racine a un package.json qui définit les workspaces.
CI/CD dans un monorepo
Le challenge : ne pas tout rebuilder à chaque commit. Les outils comme Turborepo détectent ce qui a changé. Seuls les packages affectés sont retestés/rebuildés. Le caching accélère dramatiquement les pipelines.
Quand ne pas utiliser un monorepo
Projets vraiment indépendants qui n’évoluent pas ensemble. Équipes différentes qui veulent leur autonomie. Quand la taille devient ingérable (très gros projets). Évaluez les trade-offs.
Conclusion
Le monorepo n’est pas une solution universelle, mais un outil puissant pour les projets multi-packages cohérents. Avec les bons outils, il simplifie la coordination et le partage de code.
Chez Eve Media, nous structurons les projets pour la maintenabilité. Contactez-nous pour vos architectures complexes.
