# 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

- [pnpm Workspaces Documentation](https://pnpm.io/workspaces)
- [Monorepo vs Multi-repo](https://www.atlassian.com/git/tutorials/monorepos)
- [Why pnpm?](https://pnpm.io/motivation)

---

## Validations

- [x] Discussion équipe
- [x] POC pnpm workspace
- [x] Alignement avec contraintes académiques

---

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