romain
/
ansiblenginx
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
main
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'main'
${ noResults }
ansiblenginx/app/bricolociaac/docs/architecture/ADR/001-mono-repo.md

4.0 KiB
Raw Permalink Blame History

ADR-001 : Structure Mono-repo avec pnpm Workspaces

Statut : ✅ Accepté
Date : Octobre 2025
Décideurs : Équipe Architecture
Tags : organisation, tooling

Contexte

Le projet BricoLoc Architecture Evolution comprend deux applications distinctes (Legacy et Moderne) ainsi que de la documentation partagée. Nous devons décider de l'organisation du code source.

Options considérées

  1. Multi-repo : 3 repositories séparés (legacy, modern, docs)
  2. Mono-repo : 1 seul repository avec workspaces
  3. Mono-repo hybride : 1 repo principal + submodules Git

Décision

✅ Nous adoptons un mono-repo avec pnpm workspaces

Justification

Avantages du Mono-repo

1. Cohérence

  • Documentation et code au même endroit
  • Versioning unifié (1 tag = 1 version du projet)
  • Évolution synchronisée des 2 applications

2. Collaboration Facilitée

  • Un seul repository à cloner
  • Pull Requests centralisées
  • CI/CD unique

3. Code Partagé

  • Types TypeScript communs (packages/shared-types)
  • Utilitaires réutilisables
  • Constantes (entrepôts, catégories)

4. Simplicité Opérationnelle

  • 1 seul .git à gérer
  • 1 seul CI/CD à configurer
  • Déploiement simplifié

5. Pédagogique

  • Comparaison immédiate (côte à côte)
  • Navigation facile entre Legacy et Moderne
  • Historique Git complet

Pourquoi pnpm ?

Critère npm yarn pnpm
Performance ⚠️ Moyen ✅ Rapide ✅ Très rapide
Espace disque ❌ Duplication ⚠️ Cache ✅ Hard links
Workspaces ✅ Oui ✅ Oui ✅ Oui + strict
Popularité ✅✅✅ ✅✅ ✅ Croissante

pnpm est optimal pour les mono-repos :

  • Installation ultra-rapide (hard links)
  • Économie d'espace disque (1 seule copie par package)
  • Mode strict (pas de phantom dependencies)

Conséquences

✅ Positives

  • Navigation projet simplifiée
  • Refactoring inter-apps facile
  • Documentation toujours à jour
  • CI/CD centralisé
  • Onboarding rapide (1 clone)

⚠️ Négatives

  • Repository plus volumineux
  • Git history peut devenir complexe
  • Risque de couplage involontaire (à surveiller)

🛠️ Mitigations

  • Utiliser pnpm --filter pour travailler sur une app
  • Structurer clairement les dossiers
  • Code reviews strictes (pas de couplage)
  • Git hooks pour validation

Structure Adoptée

bricoloc-architecture-evolution/
├── apps/
│   ├── legacy-app/       # Application Legacy isolée
│   └── modern-app/       # Application Moderne isolée
├── packages/
│   └── shared-types/     # Types partagés (si nécessaire)
├── docs/                 # Documentation centralisée
├── tools/                # Scripts communs
├── pnpm-workspace.yaml   # Configuration workspace
└── package.json          # Root package.json

Alternatives Rejetées

❌ Multi-repo (3 repositories séparés)

Raisons du rejet :

  • Complexité de synchronisation
  • Difficulté de comparaison Legacy vs Moderne
  • Multiplication des CI/CD
  • Onboarding plus long

❌ Mono-repo avec Git submodules

Raisons du rejet :

  • Complexité Git (submodules = source d'erreurs)
  • Pas adapté pour projet académique
  • Overhead de gestion

❌ npm/yarn workspaces

Raisons du rejet :

  • pnpm plus performant
  • pnpm mode strict évite les erreurs
  • Économie d'espace significative

Références

Validations

  • Discussion équipe
  • POC pnpm workspace
  • Alignement avec contraintes académiques

Prochaine révision : Si problème majeur détecté