La gestion de plusieurs référentiels peut être frustrante, surtout si vous êtes impliqué dans ces référentiels. Par exemple, Repo A et Repo B peuvent avoir 30 % de similitudes dans la logique métier. Lorsque vous devez le réparer ou le modifier, vous devez le faire deux fois.

Avant de commencer, vous devrez peut-être jeter un œil à cet article pour avoir l'esprit plus clair :

Qu'est-ce que le monorepo ?

Contrairement au multi-repo, un monorepo est un référentiel unique qui stocke les codes et les actifs de plusieurs projets. Vous permettent de partager la logique métier entre différents projets.

Imaginez que vous utilisiez JavaScript à pile complète : Desktop — ElectronJS, Backend — NodeJS, Mobile Apps — React Native, Admin Portal — ReactJS et Web Application — SvelteJS. Vous n'avez besoin que d'un référentiel pour stocker tous ces projets.

La structure du dossier ressemblerait à ceci :

apps/
├── admin
│   └── package.json
├── api
│   └── package.json
├── desktop
│   └── package.json
├── mobile
│   └── package.json
└── web
    └── package.json
public/
├── styles
│   └── global.css
├── images
│   └── a.png
|   └── b.png
└── favicon.ico
shared/
└── utils
    └── index.ts

Qui utilise monorepo ?

1. De grandes entreprises comme Google, Facebook, Twitter, Microsoft, etc. utilisent monorepo et leur base de code est énorme.
2. Les bibliothèques open source utilisent généralement monorepo pour les sites de documentation et les plugins, etc. Cependant, il peut parfois s'agir de plusieurs dépôts.

Monorepo est bon, mais parfois il se retournera contre vous.

Avantages

1. Code Once — Vous n'avez pas besoin d'écrire plusieurs fois la même logique métier. Codez une seule fois, partagez-les sur plusieurs projets dans le même référentiel.
2. Gestion simplifiée des dépendances — Dans le multi-dépôt, vous devrez peut-être télécharger plusieurs fois la même dépendance tierce, en publiant des packages plusieurs fois ; Monorepo vous permet de gérer la dépendance en un seul endroit et une seule fois.
3. Modifications atomiques - Vous pouvez modifier un morceau de code et affecter plusieurs projets. Par exemple, lors de la refactorisation d'une fonction partagée , cela affectera également d'autres projets.

1. Contrôle d'accès - On aura accès à lire, écrire, supprimer dans tous les projets. Par exemple, John est développeur Web frontend, il ne devrait travailler que pour une application Web React, mais il a également accès au backend, au bureau, etc.
2. Plus de stockage nécessaire - Il convient à un développeur full-stack qui travaille sur la plupart des projets. Cependant, si dans monorepo il y a cinq projets mais que vous ne travaillez que sur un, les quatre autres projets gaspillent votre espace de stockage.
3. Changements atomiques - Oui, cela pourrait être à la fois un avantage et un inconvénient. La refactorisation d'un morceau de code peut réussir ou échouer complètement. Il est possible que vous gâchiez le projet de quelqu'un d'autre.
4. Importation automatique de l'IDE — Vérifiez toujours l'importation automatique de votre IDE. Parfois, il importera des modules d'autres projets, modules qui ne seront pas inclus dans la production. Veuillez ne pas vous fier au refactor intelligent d'IDE car JS n'est pas un langage de type sécurisé; cela créera un cauchemar.
5. Contrôle de version - Lorsqu'une grande équipe y contribue, il sera très difficile de suivre les journaux de validation.

Consultez l'exemple de référentiel Github ici .

Plus de contenu sur plainenglish.io