1. Positionierung
Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm.
Multi-Modul-Management-Tool zur Aufrechterhaltung der Monorepo
PSLerna ist Babels eigenes tägliches und Open-Source-Tool. Siehe Warum ist Babel ein Monorepo?
2. Monorepo
Monorepo (monolithisches Repository) ist im Gegensatz zu Multirepo ein Single-Code-Repository und ein Multi-Code-Repository (ein Repository pro Modul).
Multirepo ist der traditionelle Ansatz. Es ist durch Module in mehrere Codebasen unterteilt. In der Praxis wurden einige Probleme festgestellt:
Das Issue-Management ist chaotisch, und Modulprobleme werden häufig im Core-Repo angesprochen. Sie müssen dies schließen und nachverfolgen
Das Änderungsprotokoll ist schwer zu integrieren, und es ist erforderlich, alle geänderten Lager manuell zu sortieren und zu integrieren
Das Update der Core-Repo-Version ist problematisch. Sie müssen alle Module synchronisieren, um ihre abhängigen Core-Repo-Versionen zu aktualisieren
Monorepo fügt alle zugehörigen Module in ein Repo ein. Jedes Modul wird unabhängig veröffentlicht, verwendet jedoch dieselbe Versionsnummer (wie Babel und React) für das Repo. Probleme und PRs sind im Repo konzentriert, und das Änderungsprotokoll kann einfach von einer Kopie kopiert werden. Die Festschreibungsliste wird aussortiert (selbst wenn das Issue-Tag der Festschreibungsspezifikation zugeordnet ist, kann automatisch ein standardisiertes Änderungsprotokoll erstellt werden).
Monorepo hat auch einige Probleme, aber nicht so stark wie die oben genannten Schmerzpunkte:
Die Größe des Repos ist groß, was zu Problemen bei der Versionskontrolle führen kann (Git ist nicht für die Verwaltung großer Repos geeignet).
Unified Build Tools stellen höhere Anforderungen an Build Tools, um verschiedene verwandte Module erstellen zu können
Aus der Sicht des Quellcode-Managements sind Multirepo und Monorepo zwei unterschiedliche Konzepte: Ersteres ermöglicht eine abwechslungsreiche Entwicklung, und jedes Modul kann sein eigenes Gameplay (Build, Abhängigkeitsmanagement, Komponententests usw.) haben, während letzteres das Management zentralisieren und das Gameplay reduzieren möchte. Kommunikationskosten durch Unterschiede
Das Markenzeichen von monorepo ist die Verzeichnisstruktur, z. B. React:
react-16.2.0/
packages/
react/
react-art/
react-.../
Jedes Modul hat seine eigenen Abhängigkeiten (package.json), die als unabhängiges npm-Paket freigegeben werden können, der Quellcode wird jedoch zusammen beibehalten
Typischer Fall:
Rollup: Multirepo
babel: monorepo
Wenn Sie Probleme mit dem Rollup haben, bevor Sie PS verwenden, gehen Sie zuerst zum Haupt-Repo, um verwandte Probleme zu überprüfen, suchen Sie dann das entsprechende Plugin-Repo gemäß den Hinweisen und überprüfen Sie dann verwandte Probleme. Ich habe mich immer sehr mühsam gefühlt und kann nicht sagen, was falsch ist. Es stellte sich heraus, dass es sich um Probleme handelte, die durch die Organisation des Quellcodes verursacht wurden.
Three.lerna spielen
// 安装
npm install lerna -g
git init hoho-lerna && cd hoho-lerna
// 初始化目录结构
lerna init
Holen Sie sich die folgende Struktur:
hoho-lerna/
packages/
lerna.json
package.jsonErstellen Sie ein Modul:
mkdir packages/hoho-lerna-core && cd packages/hoho-lerna-core
npm init
Dies wird mit einer Reihe von Paketen enden:
packages/
hoho-lerna-core/
package.json
hoho-lerna-module-a/
package.json
hoho-lerna-module-b/
package.json
module.../
Was wir tatsächlich tun, ist, nach Modulen in Pakete aufzuteilen und die Abhängigkeiten zwischen Paketen zu deklarieren (über package.json auf Modulebene).
Abhängigkeitsverarbeitung
Wenn ModulA vom Kern abhängt, wird nach der Verarbeitung der Abhängigkeit über den Befehl lerna bootstrap unter node_modules von moduleA ein Softlink erstellt, der auf das Kernverzeichnis verweist. Es gibt ein lebendes Beispiel
Hinweis: npm installiert PeerDependencies nicht automatisch und lerna bietet diesen Service auch nicht an
lerna bootstrap ordnet die Pakete tatsächlich zu, indem Softlinks gemäß den zuvor deklarierten Abhängigkeiten eingerichtet werden
Da die freigegebenen Pakete alle in Paketen abgelegt sind, ist es einfach, sie einheitlich zu verwalten, sodass die Freigabe aller Pakete mit einem Klick an npm unterstützt wird
PS muss über ein npm-Konto (Selbstregistrierung) verfügen und der lokalen Konfiguration einen npm-Adduser hinzufügen
Nachdem ich mich fertig gemacht habe, kann ich es kaum erwarten, mit einem Pfeil zu beginnen:
Wenn die Veröffentlichung von lerna
nicht unerwartet ist, erhalten Sie eine ähnliche Ausgabe:
lerna info version 2.7.0
lerna info current version 0.0.0
lerna info Checking for updated packages...
lerna info Comparing with initial commit.
lerna info Checking for prereleased packages...
? Select a new version (currently 0.0.0) Major (1.0.0)
Changes:
- hoho-lerna-core: 1.0.0 => 1.0.0
- hoho-lerna-module-a: 1.0.0 => 1.0.0
- hoho-lerna-module-b: 1.0.0 => 1.0.0
? Are you sure you want to publish the above changes? Yes
lerna info publish Publishing packages to npm...
lerna info published hoho-lerna-module-b
lerna info published hoho-lerna-core
lerna info published hoho-lerna-module-a
lerna info git Pushing tags...
Successfully published:
- [email protected]
- [email protected]
- [email protected]
lerna success publish finished
Dann gibt es 3 Junk-Pakete in der npm-Registrierung ...
Der allgemeine Veröffentlichungsprozess ist:
Tag lokal (zB git tag v1.0.0)
Beispiel für die automatische Aktualisierung der Abhängigkeitsversionsnummer
Veröffentlichen Sie dann jedes Paket auf npm
Drücken Sie abschließend das Tag und das entsprechende Commit
Hinweis: Wenn der Schritt des Publizierens auf npm fehlschlägt (z. B. ist das npm-Konto nicht konfiguriert), kann die nächste direkte lerna-Veröffentlichung nicht direkt veröffentlicht werden. Es scheint, dass das lokale Tag bereits v1.0.0 ist und die letzte Veröffentlichung erfolgreich war. Es ist nicht möglich, dieses Tag manuell auszurollen. Möglicherweise wird ein Versionsstatus in .git aufgezeichnet. Nach dem Abrollen wird ein Commit-Hash-Matching-Fehler angezeigt, der hier nicht sehr freundlich ist.
PS Weitere Befehle finden Sie unter Lerna
Um automatisch ein Änderungsprotokoll zu generieren
, installieren Sie zuerst das Änderungsprotokoll-Tool:
npm install lerna-changelog -g
Fügen Sie dann die entsprechenden Konfigurationselemente in lerna.json hinzu:
"changelog": {
"repo": "ayqy/hoho-lerna",
"labels": {
"enhancement": ":rocket: Enhancement",
"bug": ":bug: Bug Fix",
"doc": "Refine Doc",
"feat": "New Feature"
},
"cacheDir": ".changelog"
}
Besonderer Hinweis: Repo ist erforderlich, es wird gesagt, dass es automatisch abgeleitet wird, aber es ist in der Tat nicht sehr zuverlässig, siehe Das automatisch abgeleitete Feld The'repo 'ist fehlgeschlagen, aber es ist kein Fehler aufgetreten
In PSlabels ist key das in Github zu konfigurierende Label, das zur Klassifizierung von Issue / PR verwendet wird. Der Wert in: bug: Nur ein ungezogenes Emoji. Es wird als Titel für diese Art von Änderung im Changelog verwendet
Es ist noch nicht vorbei, aber Sie benötigen auch Github-Repo-Berechtigungen (um Issue, PR überprüfen zu können) und das Token als Umgebungsvariable verfügbar zu machen (Sie können es zu ~ / .bash_profile hinzufügen, wenn Sie häufig verwendet werden):
export GITHUB_AUTH="..."
Die Konfiguration ist abgeschlossen. Um "automatisch" zu erreichen, wird vorausgesetzt, dass die tägliche Entwicklung und Wartung den vereinbarten Spezifikationen entspricht, da das Tool sonst das Änderungsprotokoll am Ende definitiv nicht erraten kann. Die Spezifikation bezieht sich auf:
(Empfehlung) Entsprechendes Problem im Zusammenhang mit der Festschreibungsnachricht
(Erforderlich) Wählen Sie beim Erstellen von PR unser vordefiniertes Label
Da das Tool die PR nur mit der angegebenen Bezeichnung auf github sortiert und die Festschreibungsnachricht als Änderungsprotokollelement verwendet, wird empfohlen, das Problem in der Festschreibungsnachricht zuzuordnen, und das generierte Änderungsprotokoll kann dem entsprechenden Problem zugeordnet werden:
Uses github PR/Issue names categorized by labels with configurable headings.Z.B:
git cm -m "feat: changelog, Close #1"
Senden Sie dann eine PR und fügen Sie das Label ein: feat, ziehen Sie nach dem Zusammenführen den lokalen Pull, um lerna-changelog zu versuchen:
## Unreleased (2018-01-13)
#### New Feature
* [#2](https://github.com/ayqy/hoho-lerna/pull/2) feat: changelog, Closes [#1](https://github.com/ayqy/hoho-lerna/issues/1). ([@ayqy](https://github.com/ayqy))
#### Committers: 1
- 黯羽轻扬 ([ayqy](https://github.com/ayqy))
相当漂亮：https://github.com/ayqy/hoho-lerna/releases/tag/v1.1.0PS sollte die lokal generierte temporäre Änderungsprotokolldatei in .gitignore ignorieren, nur das lokale Lerna-Änderungsprotokoll, wenn eine neue Version veröffentlicht wird, und das generierte Änderungsprotokoll in der Versionshinweis veröffentlichen. Das nicht automatische Freigeben von Versionshinweisen kann auf API-Einschränkungen oder aus vorsichtigen Überlegungen zurückzuführen sein. Schließlich sind Versionshinweise noch wichtiger
Darüber hinaus hängt das automatische Sortieren des Änderungsprotokolls auf diese Weise tatsächlich von den Einschränkungen in der Entwicklung ab (PR-Etikettenspezifikation, Festschreibungsnachricht als Spezifikation des Änderungsprotokollelements), was nichts mit lerna zu tun hat, solange es sich um ein Monorepo handelt (Ausgabe / PR). Wenn Sie sie zusammenstellen, können Sie Informationen zu Problemen / PR gemäß dieser Idee abrufen und das Änderungsprotokoll sortieren
Dies entspricht der Verteilung des enormen Arbeitsaufwands beim Sortieren des Änderungsprotokolls auf die tägliche Entwicklung und Wartung. Änderungen müssen PR sein, und es muss ein Problemdatensatz vorhanden sein. Wenn Sie nicht daran gewöhnt sind, ist dies immer noch sehr problematisch (es gibt einen Aufruf zur Festschreibungsnachricht, um anstelle von PR ein eigenes Label zu bringen , Es sollte in Zukunft unterstützt werden)
4. Anwendbare Szenarien In
welchen Szenarien kann Monorepo (und Lerna Management?) Verwendet werden?
Wenn es sich jedoch um ein großes Projekt handelt und 100G-Quellcode zusammen integriert ist, sollten Sie es erneut in Betracht ziehen.
Für Projekte mit mehreren Modulen / Plug-Ins ist es sehr gut geeignet, offiziell verwaltete Plugins als Pakete zu verwenden
Darüber hinaus benötigen Sie außerdem:
Infrastruktur
Teamvertrauen
Infrastruktur bezieht sich auf ein leistungsstarkes Build-Tool, das die Build-Anforderungen aller Module erfüllen kann (für ein reines Front-End-Projekt ist der Build-Druck nicht groß).
In der Monorepo-Umgebung ist es möglich und empfehlenswert, den Code anderer Personen zu ändern. Einerseits ist ein kontinuierlicher Integrationsmechanismus (wie React-CircleCI) erforderlich, um die Auswirkungen der Änderung zu bestätigen. Andererseits müssen verschiedene Teams einander vertrauen, andernfalls wird häufig ein Team angezeigt. Die Änderung wirkt sich auf die Situation eines anderen Teams aus und muss die Änderungen anderer Personen rückgängig machen, was sich auf die Effizienz auswirkt
PSLerna ist schon lange nicht mehr da (ungefähr so alt wie Babel) und viele Projekte werden verwendet
Referenz
Lerna: sehr prägnantes offizielles Dokument
monorepo new wave | lerna einführen: senior helloworld ist nicht schlecht
Schlacht im REPO-Stil: MONO VS MULTI
Mono Repository Tool Vergleich: Monorepo Tool Vergleich
Neue Wellenmodularität mit Lerna-, Monorepos- und npm-Organisationen