Feathers: RFC：コアパッケージにmonorepoでLernaを使用する

私たちはそれをすることについて話しました。 それは確かに問題追跡に役立ちます。 ZenHubの代わりにGitHubプロジェクトを使用できるかもしれません。 これは、Chrome以外のブラウザやすべてのモバイルデバイスに適しています。 あなたが投稿した2番目の組織は、すべてが機能別に整理されており、本当に素晴らしいです。

@marshallswainはhttps://github.com/blog/2272-introducing-projects-for-organizationsを検討します

https://github.com/feathersjs/feathers-hooks-common/issues/31で、すべての一般的なフックを独自のリポジトリに分割してテストドライブすることを提案しました。

私は間違いなくそれを受け入れており、おそらくv3での作業が容易になるでしょう（ @ekryskiは、新しい認証で作業するときに、これらすべての個別のリポジトリをリンクする苦痛について1つか2つ言うことができると思います）。 考慮すべき重要なことは、これが私たちが使用しているツールとどのように統合されるかです。

• コードカバレッジとレポート
• Travis CI（常にすべてのテストを実行しますか？ボーナスとして、実際の統合テストを作成できる可能性があります）

また、古いリポジトリを削除するだけですか？ 組織にそれほど多くないのはいいことです。

Travis CI（常にすべてのテストを実行しますか？ボーナスとして、実際の統合テストを作成できる可能性があります）

正確に言えば、ciのパッケージ統合は通常、bashスクリプト（タスクまたはスクリプトディレクトリ内）またはルート内のmakefileとして調整されます...例：

https://github.com/babel/babel/blob/master/scripts/test.sh
https://github.com/facebookincubator/create-react-app/blob/master/tasks/e2e.sh

create-react-appは、 e2e.shスクリプトを使用してCIフローを調整します。これは、フェザーの優れたソリューションになると思います...

または、CIサーバーにlernaをインストールし、それを使用してプロジェクトルートでhttps://github.com/lerna/lerna#runを使用してnpmスクリプトを実行するか、ieを使用して特定のパッケージにスコープを設定できると思います。
lerna run --scope feathers-hooks test

また、古いリポジトリを削除するだけですか？ 組織にそれほど多くないのはいいことです。

はい！ コミットログをコピーするlerna importを使用してlernaによって処理されます。非常に便利です。 フェザーなどのエコシステムのもう1つの利点は、lernaが共通ルートdevDependenciesを管理し、開発/ CIのインストールを高速化し、バージョンが同期してダウンストリームコンシューマーの依存関係グラフを最小限に抑えることを保証することです。

https://github.com/feathersjs/feathers-hooks-common/issues/31で返信しました

26個のフックがあります。
5は15-40LOC（コメントと空白行を含む）
15は5-15LOCです
3は1-5LOCです
残りの3つは大きくありません。 数えている間、私は彼らのサイズを見失いました。

26個のリポジトリを作成しているようには見えませんが、そのうち21行には、コメントと空白行を含めて15行未満のコードが含まれています。

@eddyystop同意します、feathers-hooks-commonを分割することは、最良のテストケースではないかもしれません[email protected]モノレポを正当化するための相互依存性

それはLOCについてではありません。 問題は、1つのフックで1つのLOCに重大な変更があり、それでもすべてのユーザーが1つのメジャーバージョンから別のメジャーバージョンへの移行全体を実行することです（つまり、依存関係のバージョンを更新し、移行ガイドを読んで、関連するものが変更されたかどうかを確認してからまったく変更されていない他の25個のフックの1つのみを使用している場合でも、すべてのテストを再実行します。

Lernaを使用するポイントは、26個のリポジトリを作成する必要はありませんが（まだ1つになっています）、npmに26個の個別のモジュールがあります。 したがって、 feathers-hooks-populateに重大な変更を加えることができますが、 feathers-hooks-iffを使用しているだけの人はそれについて心配する必要はありません。

個人的には、フックを個別にインストールする方が面倒だと思います。
新しい動作が必要な場合は、メジャーフックのバージョンを更新してもかまいません。

しかし、ええ、私は両方の側面を見ます。
2016年11月26日土曜日02:05に、 Eddyystopnotifications @ github.comは次のように書いています。

私はfeathersjs / females-hooks-common＃31で返信しました
https://github.com/feathersjs/feathers-hooks-common/issues/31 that

26個のフックがあります。
5は15-40LOC（コメントと空白行を含む）
15は5-15LOCです
3は1-5LOCです
残りの3つは大きくありません。 数えている間、私は彼らのサイズを見失いました。

26のリポジトリを作成しているようには見えませんが、そのうち21は15行未満です。
コード。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/feathersjs/feathers/issues/462#issuecomment-263038859 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AATzWBVqBS9ruRqgqrIayNzSYc61fyHuks5rB5P_gaJpZM4K0nqu
。

@dafflのポイントは公正なものです。 それはコード行ではなく、機能性に関するものであり、彼が提唱したシナリオは近い将来に起こるでしょう。 それは言われています：

フックについての考え

私はfeathers-hooks-commonを自分のリポジトリに分割することについての危機に瀕しています。 この時点で、それはやり過ぎになり始めており、私たちの側（そして開発者でさえ）のメンテナンス側はサーバー側の使用の利点をはるかに超えていると思いますが、フックはクライアント側で使用できるので（そしてそうあるべきです）、個別にインストールできます（Lodashのように）ビルドサイズを減らすことができます（Lernaでそれができるかどうかはわかりません）。

現在、現在のフックリポジトリはかなり小さいです（gzip圧縮または縮小されていない約30k）。 それはlodashのサイズにはほど遠いので、グループ化が主に機能に関するものであり、コード行ではない場合、今のところ、それらをすべて同じリポジトリにまとめる必要があると思います。 Lernaを使用すると、実際には、@ dafflでケースを処理するために、フックごとにマイクロバージョンを公開するのが簡単になる可能性があります。

レルナ/モノレポについての考え

一般的に、私は@justingreenbergに同意します。 提案をありがとう😄。 個人的には、1つの崇高なウィンドウを開くだけで、すべてを手動でシンボリックリンクする必要はありません。 新しいバージョンの認証では、すべてを公開するのは非常に困難でした（ベータ版が終了するまではまだです）。すべてのモジュールに影響を与える重大な変更があると、すべてが公開されるまでテストが中断されるためです（または、実行する必要があります）。一時的にマスターブランチを指すハックの回避策）。 私もあなたが提案した構造が好きです。 ただし、これには実際には多くの影響があり、現時点では「作業を行う」プロジェクトである可能性があるため、（少なくとも今のところは）いくつかの予約があります。 新しいリポジトリがさらに追加されるとは思いません。 たぶん5-6だけで、いくつかはなくなるでしょう。

確かにレルナと一緒に行くとしたら、独立モードを使わなければならないと思います。 ReactとReactNativeはすべてmonorepoソリューション（Lernaを使用しない）であり、それが頻繁にリリースする必要がある理由であり、非常に多くの重大な変更をリリースする理由です（これは最悪です）。 また、多くの貢献者がいる場合、競合を解決するのがはるかに困難になります。 彼らは実際にはもう少しデカップリングの過程にあります...

私たちにとってのモノレポの利点は次のとおりです。

• 開発者は、私たちが維持している部分やフェザーに関係しているものを簡単に確認できます
• 関連するモジュールの作業と公開が簡単になりました
• 新しい「リポジトリ」を追加するときに、テストとテストカバレッジが確実に追加されるようにするための作業が少なくなります
• チームメンバー間での公開などの権限を管理するための作業が少なくなります
• 最新の状態に保つためのリポジトリが少なくなります（つまり、ドキュメント、発行タグなど）
• より多くの人が問題を報告し、私たちが管理して優先順位を付けるのが簡単になります
• メジャーリリースはリリース投稿と一致する方がよいでしょう

欠点：

• 外部の貢献者は、関心のあるモジュールだけでなく、リポジトリ全体へのアクセスを許可する必要があります。 これにより、リリース/ PRをより厳密に精査する必要があるため、人々が新しいものに貢献するのが難しくなり、新しいプラグインの反復が遅くなります。
• テストの実行を高速化するために、ツールを変更する必要があります
• リリースの方法を変更する必要があるかもしれません
• すぐにリリースできない可能性があります（私たちのように聞こえますが、これは今のところリスクです）
• コードが少ないリポジトリは、エコシステム全体で行き詰まるのではなく、新しい開発者にとってより親しみやすいものです
• コードクライメートとテストカバレッジスコアは、新しいモジュールが流動的であるたびに低下し、多くの流動化が発生する可能性があります（基本的にスコアが役に立たなくなります）。
• マージの競合とリベースがさらに増えることになります。

@dafflの質問以外のその他の考慮事項：

• 例は今どこにありますか？ 各モジュールには独自の例がありますが、サイズを縮小するためにモジュールを独自のリポジトリに移動しますか？ それらをトップレベルに移動しますか、それとも現在の場所に残しますか？
• .travis.ymlファイルは今どのように見えますか？ テストを実行するには、さまざまなデータベースを起動する必要があり、それらすべてを1つのビルドでセットアップすると、ビルド時間が遅くなります。
• これはフロントエンドビルドとフロントエンドビルドサイズにどのように影響しますか？

ボーナスは、いくつかの実際の統合テストを作成できることです

^ @ daffl今それを行うことができます。 別のリポジトリでそれを行うことができます😉。 私はすでにfeathers-authenticationとfeathers-authentication-clientで統合テストを行っています。

今は新しいツールを紹介するのをためらっていますが（ツールにたくさんの変更を加えたばかりなので）、新年のBuzzardリリースで間違いなく評価しましょう。 そうは言っても、_「これは取り組むべき最も重要なことですか？」_。 エコシステムの発見は、（私たちが始めた）ドキュメントによってより良く改善でき、リポジトリの更新に関して私たちの側で物事をより効率的にするためのツールを追加できると思います。 @corymsmithは、これを行うためのいくつかのスクリプトをすでに作成しています。

これがどの程度の悪影響を与えるかを確認したいので、タイムボックス化された試運転を実行しましょう。 @ femalesjs / core-teamの1人は、1日かけてLernaに変換してみて、それがどのように機能するかを確認し、ここにあるすべての懸念事項/リスクについて報告します。 ボランティアはいますか？ 今後数か月以内に発生しない場合は、優先度の高い問題があると思います。

@ekryskiの返事は見ませんでしたが、それはすべて素晴らしい点です。 私がちょうど考えたもう一つはGreenkeeperです。 私はいくつかの簡単な調査を行いましたが、複数のpackage.jsonファイルが含まれているリポジトリに対してPRを送信できるとは思いません。 これまでのところどれほど役に立ったかを考えると、それを持たないのはショーストッパーになるでしょう。

グリーンキーパー関連： https ：//github.com/greenkeeperio/greenkeeper/issues/139

@ekryskiこれらはすべて、特に費用便益に関して良い点です

私は最近https://github.com/knitjs/knitに出くわしました。これは、lernaに匹敵しますが、糸の上に構築されており、これらの問題のいくつかに対処しているようです。

• シングルルートpackage.json
  
  
  
  • 共有の依存関係は同期されたままです
  
  
  • @dafflはgreenkeeperと連携します:)
  
  
• ビルドは、npm（travisとローカルの両方）を使用するlernaよりもはるかに高速です
• 組み込みのタスク（公開、リリースなど）が公開されているため、より柔軟で拡張が容易に見えます

もちろん、ニットはほとんど戦闘テストされておらず、私はまだそれを使用していませんが、lernaの代わりとしてこのリファレンスを提供したいと思いました。 私は休暇の後に私のプロジェクトでそれを試してみて、それがどうなるかをあなたに知らせます！

@dafflは、すぐに使用できるモノレポマルチpackage.jsonをサポートするグリーンキーパーコアの刷新を検討しています

Greenkeeperがサブフォルダーでのpackage.jsonファイルのグループ化をサポートするようになりました（https://github.com/greenkeeperio/greenkeeper/issues/139#issuecomment-381932855を参照）。したがって、これは再検討する価値があるかもしれません。

もう1つ確認する必要があるのは、GitHubサポートに連絡して、古いモジュールから既存のmonorepoリポジトリへのリダイレクトを設定できるかどうかを確認することです。

@DesignByOnyxによるこのコメントは、分散リポジトリモデルの重要な制限を強調しています。 分散リポジトリを使用すると、他のフェザープロジェクトで統合の問題を引き起こす可能性のあるPRを受け入れる可能性があります。 しかし、寄稿者がそれを認識するのは難しい場合があります。

羽のようなマルチリポジトリ設定を使用する他のプロジェクトでも、これとまったく同じ問題が発生しました。 それに依存する別のモジュールでテストするためだけに、1つのモジュールのパッチリリースを作成することになります。 かなりのオーバーヘッドです。

モノリポジトリモデルに移行することで、すべてのリポジトリでコードの変更をまとめてテストし、PRの信頼性を高めることができます。

現在、約7つの独立したリポジトリを持つフレームワークのモノリポジトリソリューションも検討しているため、これについては2セントです。 過去には、約12のプロジェクトで使用されている他の2つのフレームワークでも同じ問題に直面していたため、完全なソリューションはおそらく存在しないと言えます:-(

まず、モノレポソリューションを使用しました。 統合を確実にすることは素晴らしく、エンドツーエンドのテストを備えた完全なサンプルアプリケーションもありました。 最大の課題は、構成管理、つまりタグでした。 モジュールにタグを付ける必要があるときはいつでも、たとえばパッチの後で、モジュールのバージョン番号がGitのタグ番号と無相関になるようにリポジトリ全体にタグを付ける必要があります。または、すべてのモジュールのバージョン番号を同時にインクリメントする必要があります。 これは、FeathersJSコアのような一貫性のあるモジュールのセットのソリューションかもしれませんが、より柔軟性の高いIMHOを必要とするエコシステムのソリューションではありません。

また、主にhttps://source.android.com/setup/develop/repoに基づく独立したリポジトリとツールスイートを使用して、管理を容易にしました（サブモジュールなど、すべてを維持するのに十分ではないものも試しました。同期）。 モジュールを個別に操作する方が簡単だったため、モジュールにタグを付ける必要がある場合、他に何も影響を受けませんでした。 また、独立したリポジトリとして管理されるエンドツーエンドのテストを備えた完全なサンプルアプリケーションもありました。 モジュールから始めてアプリにジャンプして統合できるため、初心者にとってはより簡単でした。 問題は、学習曲線を伸ばす特定のツールが必要なことです。 このようなツールは、たとえば、モジュールのセットとyarn / npmのリンクを処理するためにまったく存在しない可能性があります。

私の現在の考えは、最適なツールを使用する必要があるということです。 Gitはバージョン管理を行うのに適しているので、そのために使用する必要があります。これは、ほとんど別のリポジトリを保持することを意味します。 NPMは、Gitアーティファクトを配布するためのもう1つの方法です。 実際、PRが統合の問題を引き起こす可能性があるという事実は、単一または複数のリポジトリの問題に実際には関係していませんが、統合またはエンドツーエンドのテストが存在しないという事実に関係しています。 最後になりましたが、将来は徐々にマイクロサービスに進化するので、各モジュールを、テストプラットフォームでデプロイして統合テストできるスタンドアロンアプリ（少なくともいくつかのデプロイメント構成を使用）にする必要があると思います。

私はlernaが私の言及した問題のいくつかを処理できるかどうかを言うのに十分なことを知りません、私に知らせてください。

これらはフロントエンドのみのものであるため、デプロイの問題なしに、最後にすべてを同じプロセスにプラグインするフレームワークまたはツールであるため、reactやbabelなどの例は実際には似ていないようです。 まず、Feathersにはクライアントとサーバーの部分があり、「統合されていない」環境にな​​っています。 次に、モノリシックアプリまたは複数のアプリ（別名マイクロサービス）に個別にデプロイされるFeathersを使用して独立したサービスを作成できます。

@claustresビューのメタリポジトリは、私が行っていることです。個々のリポジトリを実行してから、gitサブモジュールを介してメインの統合モノリポジトリを実行します。

@dafflこれは、新しいFeathersバージョンのために閉じることができます。

@ frank-dspeed興味深いようですが、統合の目的で「読み取り専用」モードのサブモジュールのみを使用しますか？ 実際、過去には、開発者がサブモジュールを使用してリンクされた独立したモジュールに変更をコミットできるようにしながら、統合環境で直接作業できるように、それも評価しました。 ただし、gitがサブモジュールを処理する方法が原因で、実際には使用できませんでした（つまり、デフォルトではヘッドの状態が切り離されています）。サブモジュールを前後に同期するのはそれほど簡単ではありません。

@claustres統合リポジトリは、自動化を保持し、gitフックを介して呼び出されるスクリプトを解放します

Lerna v3への移行を急いで開始し、それが進むべき道だと思います。

• 自動リンクにより、クロスリポジトリ開発がはるかに効率的になります
• 寄稿者の参入障壁を下げる
• @feathersjs名前空間内のすべてのモジュールに対して統合テストとコードカバレッジおよび品質レポートを実行する機能
• TravisCIやCodeclimateなどのサードパーティサービスで単一のリポジトリを管理するだけで大​​幅な時間の節約になります
• すべてのモジュールが同じ構造を持つことを確認するためのスクリプトを作成する簡単な方法

ツールに関する注意事項：

• Greenkeeperがmonoreposをサポートするようになりました
• 変更ログジェネレーターをhttps://github.com/lerna/lerna-changelogに変更する必要があります

インポートするリポジトリ：

• [x] @feathersjs/feathers
• [x] @feathersjs/commons
• [x] @feathersjs/errors
• [x] @feathersjs/express
• [x] @feathersjs/transport-commons
• [x] @feathersjs/socketio
• [x] @feathersjs/primus
• [x] @feathersjs/rest-client
• [x] @feathersjs/socketio-client
• [x] @feathersjs/primus-client
• [x] @feathersjs/configuration
• [x] @feathersjs/cli
• [x] generator-feathers
• [x] generator-feathers-plugin
• [x] @feathersjs/authentication
• [x] @feathersjs/authentication-local
• [x] @feathersjs/authentication-jwt
• [x] @feathersjs/authentication-oauth1
• [x] @feathersjs/authentication-oauth2
• [x] @feathersjs/authentication-client

物事がどのように進むか（弱点、利点など）に関するいくつかのレポートをここに書き留めることは、「大規模」で人気のあるフレームワークでのマルチリポジトリからモノリポジトリへの移行の実際の例として非常に価値があると確信しています。

これで完了し、すべてのFeathersコアモジュールがの新しいモノリポジトリからリリースされました。 FeathersJSの夏の要約にいくつかの利点を書きました。

一般的に、また@ bertho-zeroの助けを借りて、移行は非常にスムーズになり、最新のLernaはプロジェクトのインポートを非常に簡単にしました。 私がまだ理解していない唯一のことは、Lernaがプロジェクト間の依存関係を理解し​​、公開前にバージョン番号を更新できるかどうかです（問題は、新しいバージョンの認証プラグインの実装中に修正される循環依存関係である可能性があります） 。 すべてのテストを実行するために行う必要のあるいくつかの追加の小さな改善もありますが、それ以外に、この変更とその利点にこれまでのところ非常に満足しています。

この問題は、クローズされた後、最近のアクティビティがないため、自動的にロックされています。 関連するバグについては、この問題へのリンクを含む新しい問題を開いてください。