Definitelytyped: なぜモノレポ？

1. types下のフォルダに直接移動できます。 たとえば、 jqueryのタイプを表示するには、 https：//github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/jqueryに移動し
2. ライブラリの名前を検索できます。 たとえば、 lodashに関連する未解決の問題を検索する場合は、 https：//github.com/DefinitelyTyped/DefinitelyTyped/issues？utf8 = lodash 93＆q = is lodashにアクセスでき

このモノレポは完全に混乱していませんか？

これを行う最も簡単な方法は、 TypeSearchを使用すること

Non-monorepoは非スターターです。 多くの場合、1つの@typesパッケージで何かを変更する寄稿者は、ブレークを修正したり、新しい機能を有効にしたりするために、いくつかのダウンストリームパッケージを変更する必要があります。 これらすべてで適切なCIビルドを実行しながら、これらのPRをアトミックな方法でマージする統合された方法がないため、これはGitHubのワークフローでの絶対的な餃子の火です。 4,000個のフォルダーを確認することが問題だと思われる場合は、4,000個のリポジトリ間でGitHub設定の同期を維持しようとしていると想像し

多くの場合、1つの@typesパッケージで何かを変更する寄稿者は、ブレークを修正したり、新しい機能を有効にしたりするために、いくつかのダウンストリームパッケージを変更する必要があります。

私は@types/パッケージを書くことに慣れていないので、何かが足りないのかもしれません...

しかし、それはsemverの目的ではありませんか？
npmの他のパッケージと比較して、 @types/パッケージを実装することの何が特別なのですか？

私はそれが同じように機能することを期待しています：あなたが持っている依存グラフ。 パッケージ@types/Xおよび@types/Yを使用するダウンストリームパッケージ@types/X 。 両方とも異なる人々によって維持されています。 @types/X変更された場合、異なるバージョンで公開されるため、 @types/Yすぐに影響することはありません。 @types/Y寄稿者は、後で@types/X新しいバージョンに更新することを決定し、すべての重大な変更による問題を修正します。

おそらくその上にDefinitelyTypedメタリポジトリがあり、タイプリポジトリへのリンクのリストのみを保持しています。 次に、そのリストを調べて@types/ npm-namespaceの下にすべてのパッケージを公開するpublisherスクリプトがあります。

または、可能であれば、実装者が@types名前空間の下で直接公開できるようにします。 したがって、 DefinitelyTypedメタリポジトリはまったく必要ありません。

https://github.com/npm/npmも2kの問題です。
https://github.com/moby/mobyさらに。

最良の解決策は、作者が定義を維持することであり、これは常に奨励されてきました。

@franklinyu問題の数は問題になっているものではありません。 このリポジトリが4kを超えるタイピングを集約することを考慮すると、その膨大な数の問題は問題ありません。

本当の質問は、 DefinitelyTypedすべての型を1つのリポジトリに集約することで解決しようとしている問題は何ですか？

残念ながら、semverはパッケージの入力にはうまく機能しません。 typesパッケージのmajor.minorバージョンはjavascriptパッケージのmajor.minorと一致する必要があります。一致しないと、特定のjavascriptパッケージバージョンにどの@typesバージョンを使用するかがわかりません。

たとえば、現在[email protected]インストールすると、 @types/[email protected]もインストールされます（現在は4.14.109 ）。 ただし、 lodashタイプにバグがあると想像してください（そして、これは非常に頻繁に発生すると信じてください）。誰かがそれを修正します。 では、バージョン番号を何にバンプしますか？ 定義上、型定義への変更は、インターフェースを壊す変更（または少なくともインターフェースの追加）です。 ただし、これらのタイプは4.14ではなく4.15 4.14用であるため、バージョンを4.15.0上げることはできません。 そして、バージョン番号を5.0.0に上げたくないのは確かです。 その代わりに、インターフェイスが変更されたとしても、バージョン番号を4.14.110に上げます。これは、実際には古いインターフェイスが不正確だったためです。

@ AJ-R [OK]を、 major.minorのバージョン@type/X等しくなければならないmajor.minorのバージョンX 、およびバグがである場合@type/Xあなたはそれを修正するためにpatchバージョンを使用します。 そうですね。

それは元の質問と何の関係がありますか：モノレポと個別のリポジトリ？

申し訳ありませんが、私は明確にすべきでした-私はあなたの以前のコメントの1つに対処していました：

しかし、それは_semver_の目的ではありませんか？

すべてのタイピングを1つのリポジトリに集約することで、DefinitelyTypedが解決しようとしている問題は何ですか？

DTを4,000の個別のGitHubリポジトリに分割して解決しようとしている問題は何ですか？

TypeScriptチームメンバーは毎日PRバックログを管理し、数十のPRをマージまたはレビューします。 ボットは、取得した膨大な量のPRを監視します。 一般的なエラーをキャッチするリポジトリ全体のlintルールを実行し、役立つと思われる新しいlintルールを定期的にオンにします。 将来のコンパイラバージョンによって壊れたもので定義を見つけて修正します。

これを数千のサブリポジトリに分割すると、すべてが難しくなり、他に何も簡単になりません。 では、なぜそれを行うのでしょうか？

DTを4,000の個別のGitHubリポジトリに分割することで解決しようとしている問題は何ですか？

1. ユーザーとして、ソースにすばやく到達できます。 ソースにアクセスするためにTypeSearchのような追加のアプリを使用する必要はありません。 npmには、必要なタイピングリポジトリへの直接リンクがあります。

2. ユーザーとして、現在の問題を確認し、新しい問題を提出する方が簡単です。

   • 2kを超える問題がある1つの巨大なリポジトリを検索してフィルタリングする必要はありません。 レポーターが問題の命名規則（つまり、 [@types/name-of-package] Issue description ）に従うのを忘れた場合はどうなりますか？ 必要な問題を見つけることは決してありません。
   • そのため、重複を提出することはほとんど不可能です。

3. 寄稿者として、リポジトリにある問題の数を明確に監視できます。

   • 具体的なタイピングの問題を取得するために、（再度）何かをフィルタリングする必要はありません。 必要な問題を見逃す可能性が低くなります。
   • 問題の数を少なくするという明確な動機があります。 問題番号は、もはや責任を共有していません。
   • そのため、何年にもわたってそこにぶら下がっている問題を忘れることはほとんどありません。
     例えば。 2013年から1ページ、2014年から5ページというように続きます。

4. TypeScriptチームのメンバーとして、たくさんのnpmパッケージの何千もの型を維持/マージ/レビューする代わりに、typescript自体の改善（jsdocサポートなど）により多くの時間を費やしました。
   成熟したエコシステムでは、それがコミュニティがすべきことです。

   • 一般的なエラーをキャッチするレポ全体のlintルールを実行します

     推奨されるすべてのルールを使用してlintプリセットをリリースし、すべての寄稿者にそのプリセットの最新バージョンを使用するようにアドバイスしてください。

   • 将来のコンパイラバージョンによって壊れたもので定義を見つけて修正します。

     それがコミュニティの貢献者がすべきことです。 予想されるts-compilerのバージョンは、typing-packageのpackage.jsonのpeerDependencyセクションに明確に記載されている必要があるため、間違った環境で使用すると警告が表示されます。

あなたは、タイピングは実際には誰もが所有しているという考え方からこれに取り組んでいます。 現実には、このリポジトリ内のファイルの大部分は、dts-genを実行し、いくつかの修正を加えてチェックインした人によって1回書き込まれ、その後、他の3人によって年に1回修正されました。 ここには強力な所有モデルはありませんし、存在する必要もありません。

これらのリポジトリの1つのアドホックな自己宣言された「所有者」がそれを維持することをやめることを決定するとどうなりますか？ これは常に発生し

これはまた、修正を提出したい人々の生活を悪化させるだけです。 昨年、数百のファイルでダウンストリームの変更を必要とするタイプパラメーターをReact定義ファイルに追加しました。 誰かが数百のリポジトリ（ああ、そしてどのリポジトリ？）を複製して広範囲の変更を行い、次に数百の同時プル要求を管理したいですか？ このためのツールすらありません。

TypeScriptチームのメンバーとして、たくさんのnpmパッケージの何千もの型を維持/マージ/レビューする代わりに、typescript自体の改善（jsdocサポートなど）により多くの時間を費やしました。 成熟したエコシステムでは、それがコミュニティがすべきことです。

私たちは文字通りこれを試しましたが、うまくいきませんでした。 DTはコミュニティ主導であり、プルリクエストのバックログは数百もの深さでした。 それ以来、PRの量が約200 /月から約1,000 /月になっているにもかかわらず、PRをマージする平均時間は2週間から4日に短縮されました（これは意図的な最小値であるため、人々は変更を検討する時間があります）。 。

さて、私は私の最初の質問「なぜモノレポ？」に対する答えがあると思います：
TypeScriptチームが型定義を維持するのが簡単だからです（型の依存関係、ダウンストリームパッケージのアトミック更新、CI、リンティングなどを考慮して）

TypeScriptチームが何千ものパッケージを維持する上でそのような主要な役割を果たしているモデルは、ほとんどがそれ自体で少し奇妙だと思います。 特にモジュール式のコミュニティ主導のnpmの世界では。

しかし、このモデルがあなたのために働くならば。 それならOK：smiley：

@ art-inこの1つのリポジトリからすべてのタイプを管理することを意図しているとは思いません。それは、パッケージ自体によって提供されていないタイプを管理することです。 パッケージがそのパッケージのタイプを公開したい場合は、パッケージ内で直接公開できます。 DefinitelyTypedは、元のパッケージメンテナの同意を必要とせずに型を集約できる場所です。