MoonManager v4 — Architecture apps vs packages
Photo by Safar Safarov on Unsplash
Retour d'expérience complet sur la séparation apps/packages dans un monorepo Turborepo + Symfony + PNPM.
Après 6 mois d'itérations, MoonManager v4 a stabilisé une architecture où 4 apps partagent 15 packages — avec un temps de refactoring réduit de ~40%.
Photo by Ilya Pavlov on Unsplash
L'article couvre : la règle "apps = intégrateurs, packages = business", les cas concrets de migration, et les pièges à éviter quand on démarre un monorepo.
Le problème des monorepos mal structurés
Quand on démarre un monorepo, la tentation est de tout mettre dans apps/. Chaque nouvelle fonctionnalité crée une nouvelle app, et on se retrouve rapidement avec 15 apps qui partagent du code via des copier-coller.
La règle MoonManager v4 est simple : les apps sont des intégrateurs, les packages portent la logique métier.
Concrètement
- apps/ : routing URL, config sécurité, système utilisateur, wiring des packages. Aucune logique métier.
- packages/ : services, controllers, entités Doctrine, composants Svelte, commandes CLI. Tout le réutilisable.
Résultat après 6 mois
Une même base de packages sert 4 apps différentes (miguel, cockpit, démo, legacy). Les tests sont mutualisés via @monwoo/e2e-kit. Le temps de refactoring a baissé de ~40%.
Conseil : si vous hésitez entre "mettre dans l'app" ou "mettre dans un package", mettez dans le package. Vous migrerez l'app plus facilement quand le framework changera.
