Monorepo avec PHP : organisation du code et bonnes pratiques

Monorepo avec PHP : organisation du code et meilleures pratiques

Dans le développement PHP moderne, la question de l'organisation efficace du code se pose de plus en plus. L'approche traditionnelle avec de multiples dépôts séparés (multirepo) a ses inconvénients : complexité de synchronisation des versions, duplication des configurations et problèmes de refactoring. Une alternative est le monorepo — une stratégie où tous les projets, paquets et bibliothèques associés sont stockés dans un seul dépôt. Dans cet article, nous verrons comment organiser un monorepo avec PHP, quels outils utiliser et quels pièges éviter.

Qu'est-ce qu'un monorepo et pourquoi est-il utile pour les projets PHP ?

Un monorepo est un stockage de code unique contenant plusieurs projets ou paquets. Dans le monde PHP, un exemple classique est Laravel, qui inclut le framework, les paquets d'authentification, de files d'attente, de messagerie et d'autres composants dans un seul dépôt.

Principaux avantages pour les projets PHP :

• Simplification du refactoring — les modifications dans un paquet sont immédiatement visibles pour tous les composants dépendants, sans avoir à publier et mettre à jour les versions de chaque paquet séparément.
• Intégrité des versions — tous les paquets utilisent la même version des dépendances, ce qui élimine les conflits de types.
• CI/CD unifié — un seul pipeline de build pour tous les composants, simplifiant les tests des modifications inter-paquets.
• Amélioration du travail collaboratif — les développeurs voient tout le code du projet, ce qui facilite les revues de code et le maintien de normes de codage uniformes.

Cependant, le monorepo ne convient pas à tout le monde. Si vos projets sont faiblement liés ou ont des cycles de publication différents, le multirepo peut être plus pratique. Pour les projets PHP moyens et grands avec une intégration étroite des composants, le monorepo devient souvent le choix optimal.

Structure d'un monorepo PHP

Une structure correcte est la base d'un monorepo réussi. Examinons une organisation typique avec un exemple de projet comprenant un noyau (core), plusieurs modules et des tests.

my-php-monorepo/├── packages/│   ├── core/│   │   ├── src/│   │   │   └── CoreService.php│   │   ├── tests/│   │   └── composer.json│   ├── module-auth/│   │   ├── src/│   │   ├── tests/│   │   └── composer.json│   └── module-payment/│       ├── src/│       ├── tests/│       └── composer.json├── apps/│   ├── api/│   │   ├── public/│   │   ├── src/│   │   └── composer.json│   └── console/│       ├── src/│       └── composer.json├── tests/│   └── IntegrationTest.php├── composer.json (racine)├── phpunit.xml.dist├── .gitignore└── README.md

Principes clés d'organisation :

• Séparation en paquets (packages) — chaque paquet a son propre composer.json avec un nom, un autoloading et des dépendances.
• Applications (apps) — points d'entrée (API, commandes console) qui rassemblent les paquets.
• composer.json racine — contient la méta-configuration pour travailler avec le monorepo.

Configuration du composer.json racine

Pour que le monorepo fonctionne, il est nécessaire de configurer le composer.json racine de sorte que les paquets soient disponibles localement, sans publication sur Packagist.

{    "name": "my-company/my-monorepo",    "type": "project",    "require": {        "php": "^8.1",        "my-company/core": "*",        "my-company/module-auth": "*",        "my-company/module-payment": "*"    },    "autoload": {        "psr-4": {            "MyCompany\\\\": "packages/"        }    },    "repositories": [        {            "type": "path",            "url": "packages/*",            "options": {                "symlink": true            }        }    ],    "scripts": {        "