Monorepo : un repo pour les gouverner tous
Un monorepo héberge plusieurs projets (apps, packages, services) dans un seul repository Git. Google, Meta, Microsoft utilisent cette approche à grande échelle. Les outils modernes rendent les monorepos accessibles à tous. Chez Eve Media, nous utilisons les monorepos pour nos projets fullstack.
Monorepo vs polyrepo
Le polyrepo (un repo par projet) isole mais fragmente. Les mises à jour de shared code nécessitent plusieurs PRs. Le monorepo unifie : un commit peut mettre à jour l’app, l’API et les packages partagés ensemble.
Avantages du monorepo
Atomic commits : modifiez frontend et backend ensemble. Partage de code facilité : les packages internes sont importés directement. Refactoring simplifié : renommez partout en un seul PR. Cohérence : même config, mêmes standards partout.
Les outils modernes
Turborepo (Vercel), Nx, pnpm workspaces, Yarn workspaces sont les solutions populaires. Ils gèrent le caching des builds, l’exécution parallèle des tasks, les dépendances entre packages.
Turborepo
Turborepo excelle en simplicité et performance. Le remote caching partage les builds entre développeurs et CI. L’exécution des tasks respecte le graph de dépendances. Configuration minimale pour démarrer.
Nx
Nx est plus complet avec des generators, des plugins pour chaque framework, et une analyse avancée des dépendances. Plus de setup mais plus de puissance pour les très grands monorepos.
Structure typique
apps/ contient les applications (web, mobile, API). packages/ contient le code partagé (ui, utils, config). La racine a le package.json principal et les configs partagées. Chaque sous-projet a son propre package.json.
Shared packages
Créez des packages pour le code réutilisé : composants UI, utilitaires, types TypeScript, config ESLint/Prettier. Ces packages sont versionnés ensemble et toujours synchronisés.
CI/CD en monorepo
Le CI doit être intelligent : ne pas tout rebuilder à chaque commit. Turborepo et Nx détectent les packages affectés par un changement. Seuls les tests et builds nécessaires sont exécutés.
Défis du monorepo
Le repo peut devenir gros (Git scale bien mais les IDE moins). Les permissions granulaires sont plus complexes (CODEOWNERS aide). La courbe d’apprentissage des outils existe mais est rentabilisée.
Quand choisir le monorepo
Projets avec du code partagé entre apps. Équipes qui travaillent sur plusieurs parties du système. Stacks homogènes (tout en TypeScript par exemple). Pour des projets vraiment indépendants, le polyrepo peut être plus simple.
Conclusion
Le monorepo est une approche puissante pour les projets modernes, surtout en TypeScript où le partage de types est précieux. Les outils actuels ont résolu les problèmes historiques de performance.
Chez Eve Media, nous structurons nos projets en monorepo quand approprié. Contactez-nous pour vos architectures de code.
