1.ポジショニング
Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm.
モノレポの維持に役立つマルチモジュール管理ツール
PSLernaは、バベル独自の毎日のオープンソースツールです。バベルがモノレポである理由を参照してください。
2. Monorepo
Monorepo（モノリシックリポジトリ）は、multirepoとは対照的に、シングルコードリポジトリとマルチコードリポジトリ（モジュールごとに1つのリポジトリ）です。
マルチレポは従来のアプローチであり、モジュールごとに複数のコードベースに分割されています。実際には、いくつかの問題が見つかりました。
問題管理は混沌としており、モジュールの問題はコアリポジトリで発生することが多いため、これを閉じて追跡する必要があります
変更ログは統合が難しく、変更されたすべてのウェアハウスを手動で分類して統合する必要があります。
コアリポジトリのバージョンの更新は面倒です。依存するコアリポジトリのバージョンを更新するには、すべてのモジュールを同期する必要があります。
Monorepoは、関連するすべてのモジュールをリポジトリに配置します。各モジュールは個別にリリースされますが、リポジトリと同じバージョン番号（BabelやReactなど）を使用します。問題とPRはリポジトリに集中し、変更ログは1つのコピーから簡単にコピーできます。コミットリストが整理されます（問題タグがコミット仕様に関連付けられている場合でも、標準化された変更ログを自動的に生成できます）
モノレポにもいくつかの問題がありますが、上記の問題点ほど強くはありません。
リポジトリのサイズが大きいため、バージョン制御の問題が発生する可能性があります（Gitは大きなリポジトリの管理には適していません）
統合されたビルドツールは、さまざまな関連モジュールをビルドできるように、ビルドツールのより高い要件を提案します
ソースコード管理の観点から、マルチレポとモノレポは2つの異なる概念です。前者は多様な開発を可能にし、各モジュールは独自のゲームプレイ（ビルド、依存関係管理、ユニットテストなど）を持つことができますが、後者は管理を一元化してゲームプレイを減らすことを望んでいます。違いによる通信コスト
monorepoの特徴は、React：などのディレクトリ構造です。
react-16.2.0/
packages/
react/
react-art/
react-.../
各モジュールには独自の依存関係（package.json）があり、独立したnpmパッケージとしてリリースできますが、ソースコードは一緒に維持されます
典型的なケース：
ロールアップ：マルチレポ
バベル：モノレポ
PSを使用する前にロールアップで問題が発生した場合は、最初にメインリポジトリに移動して関連する問題を確認し、次に手がかりに従って対応するプラグインリポジトリを見つけてから、関連する問題を確認します。いつもとても面倒くさいので、何が悪いのかわからないのですが、ソースコードの整理が原因のトラブルでした。
Three.lernaプレイ
// 安装
npm install lerna -g
git init hoho-lerna && cd hoho-lerna
// 初始化目录结构
lerna init
次の構造を取得します。
hoho-lerna/
packages/
lerna.json
package.jsonモジュールを作成します。
mkdir packages/hoho-lerna-core && cd packages/hoho-lerna-core
npm init
これは、パッケージの束で終わります：
packages/
hoho-lerna-core/
package.json
hoho-lerna-module-a/
package.json
hoho-lerna-module-b/
package.json
module.../
実際に行うことは、モジュールごとにパッケージに分割され、パッケージ間の依存関係を（モジュールレベルのpackage.jsonを介して）宣言します。
依存関係の処理
moduleAがコアに依存している場合、lerna bootstrapコマンドを使用して依存関係を処理した後、moduleAのnode_modulesの下に、コアディレクトリを指すソフトリンクが作成されます。実際の例があります。
注：npmはpeerDependenciesを自動的にインストールせず、lernaはこのサービスを提供しません
Lernaブートストラップは、以前に宣言された依存関係に従ってソフトリンクを確立することにより、実際にパッケージを関連付けます
リリースされたパッケージ
はすべてパッケージに配置されているため、一律に管理しやすく、すべてのパッケージをワンクリックでnpmにリリースできます。
PSにはnpmアカウント（自己登録）が必要であり、ローカル構成にnpmadduserを追加する必要があります
準備ができたら、矢印から始めるのが待ちきれません。
lernaの公開が
予期しないものでない場合は、同様の出力が得られます。
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
次に、npmレジストリに3つのジャンクパッケージがあります...
公開の一般的なプロセスは次のとおりです。
ローカルでタグ付けします（例：git tag v1.0.0）
依存関係のバージョン番号を自動的に更新する例
次に、各パッケージをnpmに公開します
最後に、タグと対応するコミットをプッシュします
注：npmへの公開ステップが失敗した場合（たとえば、npmアカウントが構成されていない場合）、次の直接lerna公開は直接公開できません。ローカルタグはすでにv1.0.0であり、最後の公開は成功したようです。このタグを手動でロールアウトすることはできません。一部のリリースステータスは.gitに記録される場合があります。ロールオフ後、コミットハッシュマッチングエラーが表示されますが、ここではあまりわかりません。
PSその他のコマンドについては、Lernaを確認してください
変更ログを自動的に生成
するには、最初に変更ログツールをインストールします。
npm install lerna-changelog -g
次に、対応する構成アイテムをlerna.jsonに追加します。
"changelog": {
"repo": "ayqy/hoho-lerna",
"labels": {
"enhancement": ":rocket: Enhancement",
"bug": ":bug: Bug Fix",
"doc": "Refine Doc",
"feat": "New Feature"
},
"cacheDir": ".changelog"
}
特記事項：レポが必要です。自動的に推測されると言われていますが、実際にはあまり信頼できません。「レポ」フィールドは自動的に推測されませんでしたが、エラーは発生しませんでした。
PSlabelsでは、keyはGithubで構成されるラベルであり、Issue / PRを分類するために使用され、値は次のとおりです。バグ：いたずらな絵文字です。変更ログでこのタイプの変更のタイトルとして使用されます。
まだ終わっていませんが、Githubリポジトリのアクセス許可（Issue、PRを確認できるようにするため）、およびトークンを環境変数として公開する必要があります（一般的に使用されている場合は、トークンを〜/ .bash_profileに追加できます）。
export GITHUB_AUTH="..."
設定が完了しました。「自動」を実現するための前提は、毎日の開発と保守が合意された仕様に準拠していることです。そうでない場合、ツールは最終的に変更ログを確実に推測できません。仕様の参照先：
（推奨）コミットメッセージに関連する対応する問題
（必須）PRを作成するときに事前定義されたラベルを選択します
ツールはgithubで指定されたラベルのPRのみを分類し、変更ログ項目としてコミットメッセージを使用するため、コミットメッセージで問題を関連付けることをお勧めします。生成された変更ログは、対応する問題に関連付けることができます。
Uses github PR/Issue names categorized by labels with configurable headings.例えば：
git cm -m "feat: changelog, Close #1"
次に、PRを送信し、ラベルを貼り付けます。feat、マージ後、ローカルプルをプルしてlerna-changelogを試してください。
## 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は、.gitignore内のローカルで生成されたchangelog一時ファイルを無視し、新しいバージョンがリリースされたときにローカルのlerna-changelogのみを無視し、生成されたchangelogをリリースノートに投稿する必要があります。リリースノートが自動的にリリースされないのは、APIの制限または慎重な考慮事項が原因である可能性があります。結局のところ、リリースノートはさらに重要です。
さらに、この方法で変更ログを自動的に分類することは、実際には開発の制約（PRのラベル指定、変更ログ項目の指定としてのコミットメッセージ）に依存します。これは、モノレポ（Issue / PR）である限り、lernaとは関係ありません。それらをまとめると、このアイデアに従って問題/ PR情報を取得し、変更ログを整理できます。
これは、変更ログを整理するという膨大な作業負荷を日常の開発と保守に分散することと同じです。変更はPRであり、問題レコードが必要です。慣れていない場合でも、非常に面倒です（PRの代わりに独自のラベルを付けるためのコミットメッセージが必要です）。 、将来的にサポートされるはずです）
4.適用可能なシナリオ
どのシナリオがmonorepoを使用できますか（そしてlerna管理を使用できますか？）？
しかし、それが巨大なプロジェクトである場合、100Gのソースコードが統合されている場合は、もう一度検討してください。
マルチモジュール/プラグインプロジェクトの場合、公式に保守されているプラグインをパッケージとして使用するのが非常に適しています
さらに、次のものも必要です。
インフラ
チームの信頼
インフラストラクチャとは、すべてのモジュールのビルドニーズを満たすことができる強力なビルドツールを指します（純粋なフロントエンドプロジェクトの場合、ビルドのプレッシャーは大きくありません）
モノレポ環境では、他の人のコードを変更することが可能であり、推奨されています。一方で、変更の影響を確認するには、継続的な統合メカニズム（React-CircleCIなど）が必要です。一方、異なるチームは相互に信頼する必要があります。そうしないと、1つのチームが現れることがよくあります。変更は別のチームの状況に影響し、他の人の変更をロールバックする必要があります。これは効率に影響します。
PSLernaは長い間（バベルとほぼ同じ年齢で）出ており、多くのプロジェクトが使用されています
参照
レルナ：非常に簡潔な公式文書
monorepo new wave | lernaを紹介します：シニアhelloworldは悪くありません
REPOスタイルの戦い：MONO VS MULTI
モノリポジトリツールの比較：モノレポツールの比較
Lerna、monorepos、およびnpm組織による新しい波のモジュール性