Definitelytyped: Pourquoi monorepo ?

1. Vous pouvez accéder directement au dossier sous types . Par exemple, pour voir les types de jquery , accédez à https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/jquery .
2. Vous pouvez rechercher le nom de la bibliothèque. Par exemple, si vous souhaitez rechercher des problèmes ouverts relatifs à lodash , vous pouvez accéder à https://github.com/DefinitelyTyped/DefinitelyTyped/issues?utf8=%E2%9C%93&q=is% 3Aissue+is%3Aopen+lodash ; ou vous pouvez utiliser la barre de recherche, qui vous redirigera vers la chaîne de requête appropriée.

Ce monorepo n'est-il pas un gâchis total ?

Le moyen le plus simple de le faire est d'utiliser le TypeSearch . Vous saurez si les types sont dans le registre, et s'ils le sont, le lien dans la description de npm pointera exactement vers leur sous-dossier.

Non-monorepo est un non-starter. Fréquemment, les contributeurs modifiant quelque chose dans un package @types auront besoin de modifier plusieurs packages en aval pour corriger les coupures ou activer de nouvelles fonctionnalités ; il s'agit d'un incendie de poubelle absolu avec le flux de travail de GitHub, car il n'existe aucun moyen intégré de fusionner ces PR de manière atomique tout en exécutant des versions de CI sensibles sur chacun d'eux. Si vous pensez que regarder 4 000 dossiers est un problème, imaginez- nous essayer de garder les paramètres GitHub synchronisés sur 4 000 dépôts.

Fréquemment, les contributeurs modifiant quelque chose dans un package @types devront modifier plusieurs packages en aval pour corriger les ruptures ou activer de nouvelles fonctionnalités

Je ne suis pas habitué à écrire des packages @types/ , alors peut-être que j'ai raté quelque chose...

Mais n'est-ce pas à ça que sert semver ?
Qu'y a-t-il de si spécial dans l'implémentation du package @types/ , par rapport à tout autre package dans npm ?

Je m'attends à ce que cela fonctionne de la même manière: graphique de dépendance où vous avez par exemple. package @types/X et package en aval @types/Y qui utilise @types/X . Les deux entretenus par des personnes différentes. Lorsque @types/X change, il est publié avec une version différente, donc cela n'affectera pas immédiatement @types/Y . Le contributeur de @types/Y décide plus tard de mettre à jour vers une version plus récente de @types/X et corrige les problèmes dus à tous les changements de rupture.

En plus de cela, vous avez probablement DefinitelyTyped méta-référentiel publisher qui parcourt cette liste et publie tous les packages sous @types/ npm-namespace.

Ou si c'est possible, autorisez simplement les implémenteurs à publier directement sous l'espace @types noms DefinitelyTyped meta-repo.

https://github.com/npm/npm également des problèmes de 2k.
https://github.com/moby/moby encore plus.

La meilleure solution est que l'auteur maintienne la définition, ce qui a toujours été encouragé.

@franklinyu Le nombre de problèmes n'est pas ce qui est en cause. Compte tenu de ce repo agrège > 4k dactylographies, ce grand nombre de problèmes est ok.

La vraie question est : quel problème DefinitelyTyped essaie de résoudre en agrégeant toutes les saisies dans un seul dépôt ?

Malheureusement, semver ne fonctionne pas bien pour les paquets de saisie. La version major.minor du package types doit correspondre au major.minor du package javascript, sinon les gens n'auront aucune idée de la version @types à utiliser pour une version donnée du package javascript.

Par exemple, en ce moment, si vous installez [email protected] , vous installerez également @types/[email protected] (en ce moment c'est à 4.14.109 ). Cependant, imaginez qu'il y ait un bogue dans les types lodash (et croyez-moi, cela arrive très souvent), et que quelqu'un le corrige. Maintenant, à quoi ajoutons-nous le numéro de version ? Par définition, toute modification des définitions de type est une modification de rupture d'interface (ou au moins un ajout d'interface). Mais nous ne pouvons pas faire passer la version à 4.15.0 car ces types sont pour 4.14 , pas pour 4.15 . Et nous ne voulons certainement pas faire passer le numéro de version à 5.0.0 . Au lieu de cela, nous avons remplacé le numéro de version par 4.14.110 , même s'il y a eu un changement d'interface, car l'ancienne interface était vraiment inexacte.

@aj-r Ok, la version major.minor de @type/X devrait être égale à la version major.minor de X , et s'il y a un bogue dans @type/X vous utilisez la version patch pour le corriger. Cela sonne juste.

Qu'est-ce que cela a à voir avec la question initiale : monorepo vs repos séparé ?

Désolé, j'aurais dû être clair - je parlais d'un de vos commentaires précédents :

Mais n'est-ce pas à quoi sert _semver_ ?

quel problème DefinitelyTyped essaie de résoudre en agrégeant toutes les saisies dans un seul dépôt ?

Quel problème la division de DT en 4 000 dépôts GitHub distincts va-t-elle résoudre ?

Chaque jour, un membre de l'équipe TypeScript gère le backlog des relations publiques, fusionnant ou examinant plusieurs dizaines de relations publiques. Un bot garde un œil sur l'énorme volume de PR que nous obtenons. Nous appliquons des règles Lint à l'échelle du dépôt qui détectent les erreurs courantes et nous activons régulièrement de nouvelles règles Lint lorsque nous pensons à celles qui pourraient aider. Nous trouvons et corrigeons les définitions avec des éléments cassés par les futures versions du compilateur.

Diviser cela en milliers de sous-repos rend tout cela plus difficile et ne rend rien d'autre plus facile. Alors pourquoi le ferions-nous ?

Quel problème la division de DT en 4 000 dépôts GitHub distincts va-t-elle résoudre ?

1. En tant qu'utilisateur, vous accédez plus rapidement aux sources. Vous n'avez pas besoin d'utiliser une application supplémentaire comme TypeSearch pour atteindre les sources. Sur npm, vous avez un lien directement vers le référentiel de saisie nécessaire.

2. En tant qu'utilisateur, il est plus facile de voir les problèmes actuels et d'en déposer un nouveau.

   • Vous n'avez pas besoin de rechercher et de filtrer sur un seul dépôt énorme avec plus de 2 000 problèmes. Que faire si le journaliste oublie de suivre les règles de nommage des problèmes (c'est-à-dire [@types/name-of-package] Issue description ) ? Vous ne trouvez jamais les problèmes nécessaires.
   • En tant que tel, il est moins possible de déposer des doublons.

3. En tant que contributeur, vous pouvez clairement surveiller le nombre de problèmes que vous avez dans votre référentiel.

   • Vous n'avez pas à (encore) filtrer quoi que ce soit pour obtenir des problèmes pour votre frappe concrète. Moins possible de manquer les problèmes nécessaires.
   • Vous avez une motivation claire pour garder le nombre de problèmes bas. Le numéro des problèmes n'est plus une responsabilité partagée.
   • En tant que tel, il est moins possible d'avoir oublié des problèmes pendant des années .
     Par exemple. il y a 1 page de numéro de 2013, 5 pages de numéro de 2014, et ainsi de suite.

4. En tant que membre de l'équipe TypeScript, vous avez passé plus de temps à améliorer le script lui-même (par exemple, la prise en charge de jsdoc), au lieu de maintenir/fusionner/réviser des milliers de saisies pour de nombreux packages npm.
   Dans un écosystème mature, c'est ce que la communauté devrait faire.

   • Nous appliquons des règles de lint à l'échelle du dépôt qui détectent les erreurs courantes

     Eh bien, publiez le préréglage Lint avec toutes les règles recommandées et conseillez à tous les contributeurs d'utiliser la dernière version de ce préréglage.

   • Nous trouvons et corrigeons les définitions avec des éléments cassés par les futures versions du compilateur.

     C'est ce que les contributeurs de la communauté devraient faire. La version attendue du compilateur ts doit être clairement indiquée dans la section peerDependency de package.json de typing-package, afin qu'elle vous avertisse lorsque vous l'utilisez dans un mauvais environnement.

Vous abordez cela en partant du principe que les frappes sont en réalité la propriété de n'importe qui. La réalité est que la grande majorité des fichiers de ce référentiel ont été écrits une fois par quelqu'un qui a exécuté dts-gen et l'a vérifié avec quelques corrections, puis a été retouché une fois par an par trois autres personnes. Il n'y a pas de modèle de propriété solide ici, et il n'y en a pas forcément besoin.

Que se passe-t-il lorsque le « propriétaire » ad hoc auto-déclaré d'un de ces dépôts décide d'arrêter de le maintenir ? Cela arrive tout le temps . Comment garder une trace de quel repo est le "meilleur" actuel ? Que se passe-t-il s'ils commencent à fusionner des modifications qui entraînent des choses que nous ne pouvons pas publier sur NPM ?

Cela ne fait également qu'empirer la vie des personnes qui souhaitent soumettre des correctifs. L'année dernière, nous avons ajouté un paramètre de type au fichier de définition React qui nécessitait des modifications en aval dans plusieurs centaines de fichiers. Est-ce que quelqu'un veut cloner plusieurs centaines de dépôts (oh, et quels dépôts ?) Il n'y a même pas d'outillage pour cela nulle part.

En tant que membre de l'équipe TypeScript, vous avez passé plus de temps à améliorer le script lui-même (par exemple, la prise en charge de jsdoc), au lieu de maintenir/fusionner/réviser des milliers de saisies pour de nombreux packages npm. Dans un écosystème mature, c'est ce que la communauté devrait faire.

Nous avons littéralement essayé cela et cela n'a pas fonctionné. DT était uniquement axé sur la communauté et il en a résulté un arriéré de demandes de tirage de plusieurs centaines d'années. Depuis lors, le temps moyen pour fusionner un PR est passé de 2 semaines à 4 jours (ce qui est un minimum intentionnel afin que les gens aient le temps de peser sur les changements), même si le volume de PR est passé de ~ 200/mois à ~ 1 000/mois .

Ok, je pense avoir la réponse à ma question initiale "Pourquoi monorepo ?" :
Parce qu'il est tout simplement plus facile pour l'équipe TypeScript de maintenir les définitions de type (compte tenu des dépendances de type, des mises à jour atomiques pour les packages en aval, CI, linting, etc.)

Je pense toujours que le modèle dans lequel l'équipe TypeScript joue un rôle si important dans la maintenance de milliers de packages est un peu étrange. Surtout dans le monde npm modulaire et communautaire.

Mais si ce modèle fonctionne pour vous. Alors ok :smiley:

@art-in Je ne pense pas que l'intention soit de gérer tous les types à partir de ce seul référentiel, c'est de gérer les types qui ne sont pas fournis par les packages eux-mêmes. Si un package souhaite publier des types pour son package, il peut le faire directement dans le package. DefinitelyTyped est juste un endroit où les types peuvent être agrégés sans avoir besoin du consentement du mainteneur du paquet d'origine.