Publication d'un monorepo PHP sur Packagist avec splitsh-lite

Ahnii!

Contexte de la série : Il s'agit de la partie 10 de la série Waaseyaa. Les articles précédents couvraient le système d'entités, le contrôle d'accès, la couche API, la migration DBAL, i18n, les tests, le déploiement et les packages d'IA.

Un framework qui ne peut pas être installé n'est pas un framework. C'est une démo. Cet article explique comment waaseyaa est passé d'un monorepo dont chaque sous-paquet dépendait@devchemin des référentiels vers les packages versionnés individuellement sur Packagist.

Le problème avec « il suffit de le publier »

Waaseyaa est un monorepo. La racinecomposer.jsondéfinit 43 sous-paquets sousforfaits/, chacun référencé comme un référentiel de chemins avec@devcontraintes. Pendant le développement, c'est pratique. Composer résout tout localement et vous ne pensez jamais au versioning.

Au moment où vous essayez d’enregistrer le package racine sur Packagist, le problème devient clair. Packagist ne peut pas résoudre les référentiels de chemins. Chaque"waaseyaa/entité": "@dev"dans un sous-paquetexigerblock pointe vers un répertoire local qui n’existe pas dans le registre. Le package racine ne peut pas être publié sans publier au préalable chaque sous-package.

Il ne s'agit pas d'un correctif de métadonnées. Il s'agit d'une décision architecturale concernant la manière dont le monorepo se rapporte à ses consommateurs.

Quatre stratégies, un gagnant

Avant d’écrire un code, quatre approches étaient proposées.