Why NextWhy Next
Français
← Retour à la liste
💻 Dev3 min de lecture

5 applis dans un seul dépôt : le monorepo Turborepo d'un développeur solo

Comment gérer plusieurs applis et sites web dans un seul dépôt avec un monorepo Turborepo. Partage des configs communes, économies de build grâce au cache et déploiement par appli, vu du terrain.

L'essentiel

Quand on construit plusieurs applis seul, les configs s'éparpillent. Avec un monorepo Turborepo, on partage eslint et tsconfig via packages, le cache turbo évite de rebuilder les applis inchangées, et --filter permet de déployer appli par appli.

Sur cette page

Quand on construit des applis seul, les dépôts se multiplient à toute vitesse. Une appli, un site web, encore une appli… et on se retrouve à copier-coller la config eslint cinq fois. Moi, j'ai tout fusionné dans un seul monorepo.

Le vrai problème, ce sont les configs éparpillées

Avec beaucoup de dépôts, ce qui fait le plus mal, ce n'est pas le code mais la config.

  • eslint, prettier, tsconfig copiés dans chaque dépôt
  • Un changement de règle, et il faut faire le tour de tous les dépôts
  • Les UI et utilitaires communs sont trop anecdotiques pour être publiés sur npm

Le monorepo transforme tout ça en partage depuis un seul endroit.

Structure de base

apps/
├── web/      # 랜딩
├── blog/     # 이 블로그
├── wave/     # 오늘의 파도
└── ...
packages/
├── eslint-config/       # 공용 eslint
└── typescript-config/   # 공용 tsconfig

apps/* contient les livrables déployés, packages/* les configs et le code partagés entre applis. Le tsconfig.json de chaque appli se contente d'hériter.

{ "extends": "@repo/typescript-config/nextjs.json" }

Désormais, les règles se corrigent à un seul endroit : packages.

Le cache turbo, c'est la clé

La vraie arme de Turborepo, c'est le cache. Si les entrées d'une tâche (sources, config) n'ont pas changé, le résultat précédent est réutilisé tel quel.

turbo run build            # 전체 빌드(바뀐 것만 실제로 돎)
turbo run build --filter=blog   # blog 앱만

Il suffit de déclarer dans turbo.json les dépendances entre tâches et leurs sorties.

{
  "tasks": {
    "build": { "dependsOn": ["^build"], "outputs": [".next/**"] }
  }
}

À partir du deuxième build, tout se termine en quelques secondes avec un « FULL TURBO ».

Déployer appli par appli

Même dans un dépôt unique, les déploiements restent séparés par appli. Avec Docker, turbo prune extrait uniquement le sous-arbre de l'appli concernée pour alléger l'image.

turbo prune blog --docker   # blog + 내부 의존성만 남긴 out/ 생성

Ce blog aussi a été découpé de cette façon et déployé en Docker sur un mini PC. Cette histoire est racontée dans l'article sur l'auto-hébergement.

En résumé

  • apps/* = livrables, packages/* = configs partagées
  • tsconfig et eslint gérés à un seul endroit par héritage
  • Le cache turbo ne rebuild pas les applis inchangées
  • --filter et prune pour déployer appli par appli

Si vous faites tourner plusieurs produits seul, le monorepo n'est pas un luxe : c'est un outil de survie.

Questions fréquentes

À partir de combien d'applis le monorepo devient-il rentable ?

Dès plus de 2, à partir du moment où des configs communes (eslint, tsconfig, UI) apparaissent. L'essentiel : corriger la config à un seul endroit et la voir se propager à toutes les applis.

Les builds ne deviennent-ils pas plus lents ?

Au contraire, ils accélèrent. turbo met en cache le résultat des tâches dont les entrées n'ont pas changé, et ne rebuild que les applis modifiées.

Articles similaires