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.
157 lines
4.0 KiB
Markdown
157 lines
4.0 KiB
Markdown
2 months ago
|
# 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é
|