Definitelytyped: Warum Monorepo?

1. Sie können direkt zu dem Ordner unter types navigieren. Um beispielsweise die Typen für jquery anzuzeigen, navigieren Sie zu https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/jquery .
2. Sie können nach dem Namen der Bibliothek suchen. Wenn Sie beispielsweise nach offenen Problemen im Zusammenhang mit lodash suchen möchten, können Sie https://github.com/DefinitelyTyped/DefinitelyTyped/issues?utf8=%E2%9C%93&q=is% aufrufen. 3Aissue+ist%3Aopen+lodash ; oder Sie können die Suchleiste verwenden, die Sie zum entsprechenden Abfragestring weiterleitet.

Ist dieses Monorepo nicht ein totales Durcheinander?

Am einfachsten geht das mit der TypeSearch . Sie erfahren, ob die Typen in der Registry vorhanden sind, und wenn ja, zeigt der Link in der npm-Beschreibung genau auf deren Unterordner.

Nicht-Monorepo ist ein Nichtstarter. Häufig müssen Mitwirkende, die etwas in einem @types Paket ändern, mehrere nachgelagerte Pakete ändern, um Brüche zu beheben oder neue Funktionen zu aktivieren; Dies ist ein absoluter Müllcontainer mit dem Workflow von GitHub, da es keine integrierte Möglichkeit gibt, diese PRs auf atomare Weise zusammenzuführen, während weiterhin vernünftige CI-Builds auf allen ausgeführt werden. Wenn Sie der Meinung sind, dass es ein Problem mit 4.000 Ordnern ist, stellen Sie sich vor, wir versuchen, die GitHub-Einstellungen über 4.000 Repositorys hinweg synchron zu halten.

Häufig müssen Mitwirkende, die etwas in einem @types- Paket ändern, mehrere nachgelagerte Pakete ändern, um Brüche zu beheben oder neue Funktionen zu aktivieren

Ich bin nicht mit dem Schreiben von @types/ Paketen vertraut, also kann es sein, dass ich etwas übersehe...

Aber ist es nicht das, wofür Semver da ist?
Was ist das Besondere daran, das Paket @types/ gegen jedes andere Paket in npm zu implementieren?

Ich erwarte, dass es genauso funktioniert: Abhängigkeitsdiagramm, wo Sie zB haben. Paket @types/X und nachgelagertes Paket @types/Y , das @types/X . Beide von verschiedenen Leuten gepflegt. Wenn @types/X geändert wird, wird es mit einer anderen Version veröffentlicht, sodass es nicht sofort Auswirkungen auf @types/Y . Mitwirkende von @types/Y beschließen später, auf eine neuere Version von @types/X zu aktualisieren und behebt Probleme aufgrund aller Breaking Changes.

Darüber hinaus haben Sie wahrscheinlich das Meta-Repository DefinitelyTyped , das nur eine Liste von Links zu Typ-Repositorys enthält. Und dann ein publisher Skript, das diese Liste durchgeht und alle Pakete unter @types/ npm-Namespace veröffentlicht.

Oder wenn es möglich ist, erlauben Sie den Implementierern einfach, direkt unter dem Namensraum @types . Wir brauchen also kein DefinitelyTyped Meta-Repo.

https://github.com/npm/npm auch 2k Probleme.
https://github.com/moby/moby noch mehr.

Die beste Lösung ist die Beibehaltung der Definition durch den Autor, die immer gefördert wurde.

@franklinyu Die Anzahl der Probleme steht nicht in Frage. Wenn man bedenkt, dass dieses Repo >4k Typisierungen aggregiert, ist diese große Anzahl von Problemen in Ordnung.

Die eigentliche Frage ist: Welches Problem versucht DefinitelyTyped zu lösen, indem alle Eingaben in einem Repository zusammengefasst werden?

Leider funktioniert semver nicht gut für Typisierungspakete. Die major.minor Version des Typenpakets muss mit der major.minor major.minor Version des Javascript-Pakets übereinstimmen, sonst wissen die Leute nicht, welche @types Version für eine bestimmte Javascript-Paketversion verwendet werden soll.

Wenn Sie beispielsweise jetzt [email protected] installieren, würden Sie auch @types/[email protected] installieren (im Moment ist es 4.14.109 ). Stellen Sie sich jedoch vor, es gibt einen Fehler in den Typen lodash (und glauben Sie mir, das passiert sehr oft) und jemand behebt ihn. Auf was stoßen wir nun die Versionsnummer? Per Definition ist jede Änderung an den Typdefinitionen eine Schnittstellenänderung (oder zumindest eine Schnittstellenerweiterung). Aber wir können die Version nicht auf 4.15.0 da diese Typen für 4.14 , nicht für 4.15 . Und wir wollen die Versionsnummer auf keinen Fall auf 5.0.0 . Stattdessen erhöhen wir die Versionsnummer auf 4.14.110 , obwohl es eine Schnittstellenänderung gab, weil die alte Schnittstelle in Wirklichkeit einfach ungenau war.

@aj-r Ok, major.minor Version von @type/X sollte major.minor Version von X , und wenn es einen Fehler in @type/X Sie die Version patch um das Problem zu beheben. Das klingt richtig.

Was hat das mit der ursprünglichen Frage zu tun: Monorepo vs separate Repos?

Entschuldigung, ich hätte es deutlich sagen sollen - ich habe einen Ihrer vorherigen Kommentare angesprochen:

Aber ist _semver_ nicht dafür da?

Welches Problem versucht DefinitelyTyped zu lösen, indem alle Eingaben in einem Repository zusammengefasst werden?

Welches Problem wird die Aufteilung von DT in 4.000 separate GitHub-Repositorys lösen ?

Jeden Tag verwaltet ein TypeScript-Teammitglied den PR-Backlog, führt mehrere Dutzend PRs zusammen oder überprüft sie. Ein Bot überwacht die riesige Menge an PRs, die wir erhalten. Wir führen Repository-weite Lint-Regeln aus, die häufige Fehler abfangen, und wir aktivieren regelmäßig neue Lint-Regeln, wenn wir uns überlegen, welche hilfreich sein könnten. Wir finden und beheben Definitionen mit Dingen, die von zukünftigen Compiler-Versionen beschädigt wurden.

Die Aufteilung in Tausende von Unterrepos macht all das schwieriger und macht nichts anderes einfacher. Warum sollten wir es also tun?

Welches Problem wird die Aufteilung von DT in 4.000 separate GitHub-Repos lösen?

1. Als Nutzer erreichen Sie Quellen schneller. Sie müssen keine zusätzliche App wie TypeSearch verwenden, um Quellen zu erreichen. Auf npm haben Sie einen Link direkt zum benötigten Typing-Repo.

2. Als Benutzer ist es einfacher, aktuelle Probleme zu sehen und neue einzureichen.

   • Sie müssen nicht nach einem riesigen Repo mit >2k Issues suchen und filtern. Was passiert, wenn der Reporter vergisst, die Benennungsregeln für Probleme zu befolgen (z. B. [@types/name-of-package] Issue description )? Sie finden nie benötigte Probleme.
   • Daher ist es weniger möglich, Duplikate einzureichen.

3. Als Mitwirkender können Sie klar überwachen, wie viele Probleme Sie in Ihrem Repository haben.

   • Sie müssen nichts (wieder) filtern, um Probleme für Ihre konkrete Eingabe zu erhalten. Es ist weniger möglich, benötigte Probleme zu übersehen.
   • Sie haben eine klare Motivation, die Anzahl der Probleme gering zu halten. Die Problemnummer wird nicht mehr geteilt.
   • Daher ist es weniger möglich, dass dort jahrelang vergessene Themen
     Z.B. es gibt 1 Heftseite von 2013, 5 Heftseiten von 2014 und so weiter.

4. Als Mitglied des TypeScript-Teams haben Sie mehr Zeit damit verbracht, Typescript selbst zu verbessern (zB jsdoc-Unterstützung), anstatt Tausende von Typisierungen für viele npm-Pakete zu warten/zusammenzuführen/zu überprüfen.
   In einem ausgereiften Ökosystem sollte die Community das tun.

   • Wir führen Repo-weite Lint-Regeln aus, die häufige Fehler abfangen

     Geben Sie die Fussel-Voreinstellung mit allen empfohlenen Regeln frei und raten Sie allen Mitwirkenden, die neueste Version dieser Voreinstellung zu verwenden.

   • Wir finden und beheben Definitionen mit Dingen, die von zukünftigen Compiler-Versionen beschädigt wurden.

     Das sollten Community-Mitwirkende tun. Die Version des erwarteten ts-Compilers sollte im Abschnitt peerDependency von package.json des Typing-Pakets deutlich angegeben werden, damit Sie gewarnt werden, wenn Sie ihn in einer falschen Umgebung verwenden.

Sie nähert sich diese von der Mentalität , dass Typisierungen von jemand tatsächlich im Besitz sind. Die Realität ist, dass die große Mehrheit der Dateien in diesem Repo einmal von jemandem geschrieben wurde, der dts-gen ausgeführt und mit ein paar Korrekturen eingecheckt hat, und dann einmal im Jahr von drei anderen Leuten retuschiert wurde. Hier gibt es kein starkes Eigentumsmodell und muss es auch nicht.

Was passiert, wenn der selbsternannte "Eigentümer" eines dieser Repos ad hoc beschließt, es nicht mehr zu pflegen? Dies geschieht die ganze Zeit . Wie behalten wir den Überblick, welches Repo derzeit das "beste" ist? Was passiert, wenn sie beginnen, Änderungen zusammenzuführen, die zu Dingen führen, die wir nicht auf NPM veröffentlichen können?

Dies macht auch das Leben für Leute, die Fixes einreichen wollen, nur noch schlimmer. Letztes Jahr haben wir der React-Definitionsdatei einen Typparameter hinzugefügt, der nachgelagerte Änderungen in mehreren hundert Dateien erforderte. Möchte jemand mehrere hundert Repositorys klonen (oh, und welche Repositorys?), um eine weitreichende Änderung vorzunehmen und dann mehrere hundert gleichzeitige Pull-Requests zu verwalten? Dafür gibt es nirgendwo ein Werkzeug.

Als Mitglied des TypeScript-Teams haben Sie mehr Zeit damit verbracht, Typescript selbst zu verbessern (zB jsdoc-Unterstützung), anstatt Tausende von Typisierungen für viele npm-Pakete zu warten/zusammenzuführen/zu überprüfen. In einem ausgereiften Ökosystem sollte die Community das tun.

Wir haben es buchstäblich versucht und es hat nicht funktioniert. DT wurde ausschließlich von der Community betrieben und führte zu einem hunderten tiefen Pull-Request-Backlog. Seitdem ist die durchschnittliche Zeit für die Zusammenführung einer PR von 2 Wochen auf 4 Tage gesunken (was ein absichtliches Minimum ist, damit die Leute Zeit haben, Änderungen abzuwägen), obwohl das PR-Volumen von ~200/Monat auf ~1000/Monat gestiegen ist .

Ok, ich glaube, ich habe die Antwort auf meine ursprüngliche Frage "Warum Monorepo?":
Da es für das TypeScript-Team einfach einfacher ist, Typdefinitionen zu verwalten (unter Berücksichtigung von Typabhängigkeiten, atomaren Updates für nachgelagerte Pakete, CI, Linting usw.)

Ich denke immer noch, dass das Modell, bei dem das TypeScript-Team eine so wichtige Rolle bei der Wartung von Tausenden von Paketen größtenteils alleine spielt, ein bisschen seltsam ist. Vor allem in der modularen, Community-getriebenen npm-Welt.

Aber wenn dieses Modell für Sie funktioniert. Dann ok :smiley:

@art-in Ich glaube nicht, dass die Absicht darin besteht, alle Typen aus diesem einen Repository zu verwalten, sondern Typen zu verwalten, die nicht von den Paketen selbst bereitgestellt werden. Wenn ein Paket Typen für sein Paket veröffentlichen möchte, kann es dies direkt im Paket tun. DefinitelyTyped ist nur ein Ort, an dem Typen aggregiert werden können, ohne dass die Zustimmung des ursprünglichen Paketbetreuers erforderlich ist.