Monorepo vs Polyrepo : Quelle stratégie choisir ?

Lorsqu'on travaille sur des projets logiciels complexes, le choix entre monorepo et polyrepo peut avoir un impact significatif sur la productivité de l'équipe et la scalabilité du code. Dans cet article, nous analysons les différences, les avantages et inconvénients de chaque approche, et vous aidons à comprendre laquelle est faite pour vous.

Qu'est-ce qu'un Monorepo et un Polyrepo ?

Monorepo

Un monorepo (monolithic repository) est un seul dépôt qui contient le code source de plusieurs projets, services ou packages, souvent liés entre eux.

my-monorepo/
  packages/
    frontend/
    backend/
    shared/
  package.json
  turbo.json

Polyrepo

Un polyrepo (multiple repositories) signifie que chaque projet, service ou package possède son propre dépôt séparé.

repos/
  frontend/
    package.json
  backend/
    package.json
  shared/
    package.json

Différence visuelle

Avantages et inconvénients

Monorepo

Avantages :

• Facilite le partage de code (ex. bibliothèques partagées).
• Refactoring atomique sur plusieurs projets.
• Gestion centralisée des dépendances et des configurations.

Inconvénients :

• Peut devenir lourd à mesure que le code grandit.
• Nécessite des outils pour gérer les builds/tests partiels (ex. Nx, Turborepo).

Polyrepo

Avantages :

• Chaque équipe/projet est indépendant.
• Plus simple à gérer pour les petits projets.
• Permet des politiques d'accès granulaires.

Inconvénients :

• Partage de code difficile sans publier de packages.
• Refactoring cross-repo plus complexe.
• Possibles duplications de configurations.

Exemple pratique : Monorepo avec Turborepo

Supposons que vous souhaitiez créer un monorepo avec frontend et backend en utilisant Turborepo.

1. Initialiser le monorepo

npx create-turbo@latest

2. Structure typique

my-monorepo/
  apps/
    web/        # frontend Next.js
    api/        # backend Node.js/Express
  packages/
    ui/         # bibliothèque de composants partagée
    utils/      # fonctions partagées
  turbo.json
  package.json

3. Exemple de workspace dans package.json

{
  "private": true,
  "workspaces": [
    "apps/*",
    "packages/*"
  ]
}

4. Exemple d'import d'une bibliothèque partagée

Supposons que vous ayez une fonction dans packages/utils/src/formatDate.ts :

// packages/utils/src/formatDate.ts
export function formatDate(date: Date): string {
  return date.toLocaleDateString('fr-FR');
}

Dans le frontend :

// apps/web/pages/index.tsx
import { formatDate } from '@myorg/utils';

export default function Home() {
  return <div>Nous sommes le {formatDate(new Date())}</div>;
}

Quand choisir Monorepo ?

• Équipes moyennes à grandes travaillant sur plusieurs projets liés.
• Besoin de partager du code et de faire du refactoring à grande échelle.
• Projets qui évoluent rapidement et nécessitent des builds/tests optimisés.

Quand choisir Polyrepo ?

• Petits projets ou projets indépendants.
• Équipes séparées travaillant sur des produits différents.
• Politiques d'accès très restrictives.

Conclusion

Il n'existe pas de solution parfaite pour tous. Le choix dépend de la taille de l'équipe, de la complexité des projets et des besoins de collaboration. L'important est d'être conscient des compromis et de choisir les bons outils pour gérer la complexité.