Definitelytyped: Почему монорепо?

1. Вы можете перейти непосредственно к папке под types . Например, чтобы увидеть типы для jquery , перейдите по адресу https://github.com/DefinentyTyped/DefinentyTyped/tree/master/types/jquery .
2. Вы можете искать по названию библиотеки. Например, если вы хотите найти открытые проблемы, связанные с lodash , вы можете перейти на https://github.com/DefinentyTyped/DefinentyTyped/issues?utf8=%E2%9C%93&q=is% 3Aissue + - это% 3Aopen + lodash ; или вы можете использовать панель поиска, которая перенаправит вас на соответствующую строку запроса.

Разве это монорепо не полный беспорядок?

Самый простой способ сделать это - использовать TypeSearch . Вы узнаете, есть ли типы в реестре, и если они есть, ссылка в описании npm будет указывать именно на их подпапку.

Немонорепо - это не старт. Часто участникам, модифицирующим что-либо в одном пакете @types , нужно будет изменить несколько последующих пакетов, чтобы исправить поломки или включить новые функции; это абсолютный пожар в мусорном контейнере с рабочим процессом GitHub, поскольку нет интегрированного способа атомарного слияния этих PR, при этом все еще выполняя разумные CI-сборки на всех из них. Если вы думаете, что просмотр 4000 папок - это проблема, представьте, что мы пытаемся синхронизировать настройки GitHub в 4000 репозиториях.

Часто участникам, изменяющим что-либо в одном пакете @types , необходимо будет изменить несколько последующих пакетов, чтобы исправить поломки или включить новые функции.

Я не знаком с написанием пакетов @types/ , так что, возможно, я что-то упускаю ...

Но разве семвер не для этого?
Что такого особенного в реализации пакета @types/ сравнению с любым другим пакетом в npm?

Я ожидаю, что он будет работать так же: график зависимостей, например, у вас. пакет @types/X и последующий пакет @types/Y который использует @types/X . Оба поддерживаются разными людьми. Когда изменяется @types/X , оно публикуется с другой версией, поэтому это не повлияет сразу на @types/Y . Автор @types/Y позже решает обновить до более новой версии @types/X и исправляет проблемы, связанные со всеми критическими изменениями.

Скорее всего, у вас есть мета-репозиторий DefinitelyTyped , который поддерживает только список ссылок на репозитории типов. А затем какой-нибудь сценарий publisher который проходит через этот список и публикует все пакеты в пространстве имен @types/ npm-name.

Или, если это возможно, просто разрешите разработчикам публиковать непосредственно в пространстве имен @types . Так что нам вообще не нужно мета-репо DefinitelyTyped .

https://github.com/npm/npm также 2k проблем.
https://github.com/moby/moby даже больше.

Лучшее решение - сохранить определение автором, что всегда поощрялось.

@franklinyu Количество вопросов - это не то, о чем идет речь. Принимая во внимание, что это репо объединяет> 4k типизаций, такое огромное количество проблем вполне нормально.

Реальный вопрос: какую проблему DefinitelyTyped пытается решить путем агрегирования всех типов в одном репо?

К сожалению, semver плохо работает для пакетов типизации. Версия major.minor пакета типов должна соответствовать major.minor пакета javascript, иначе люди не будут знать, какую версию @types использовать для любой данной версии пакета javascript.

Например, прямо сейчас, если вы устанавливаете [email protected] , вы также должны установить @types/[email protected] (прямо сейчас это 4.14.109 ). Однако представьте, что есть ошибка в типах lodash (и поверьте мне, это происходит очень часто), и кто-то ее исправляет. На что теперь набрать номер версии? По определению, любое изменение в определениях типов является нарушением интерфейса (или, по крайней мере, добавлением интерфейса). Но мы не можем повысить версию до 4.15.0 потому что эти типы предназначены для 4.14 , а не для 4.15 . И мы, конечно, не хотим увеличивать номер версии до 5.0.0 . Поэтому вместо этого мы увеличиваем номер версии до 4.14.110 , даже если произошло изменение интерфейса, потому что на самом деле старый интерфейс был неточным.

@ aj-r Хорошо, major.minor версия @type/X должна равняться major.minor версии X , и если есть ошибка в @type/X вы используете версию patch чтобы исправить это. Звучит правильно.

При чем здесь исходный вопрос: монорепозиторий против отдельных репозиториев?

Извините, я должен был пояснить - я отвечал на один из ваших предыдущих комментариев:

Но разве _semver_ не для этого?

Какую проблему DefinitionsTyped пытается решить, объединив все типы в одном репо?

Какая проблема является раскалывается DT в 4000 отдельных сделок РЕПО GitHub собирается решать?

Каждый день член команды TypeScript управляет бэклогом PR, объединяя или просматривая несколько десятков PR. Бот следит за огромным объемом получаемых PR. Мы запускаем правила lint для всего репозитория, которые выявляют распространенные ошибки, и мы регулярно включаем новые правила lint, когда думаем о тех, которые могут помочь. Мы находим и исправляем определения с вещами, нарушенными в будущих версиях компилятора.

Разделение этого на тысячи подрепо все усложняет и не делает ничего проще. Так зачем нам это делать?

Какую проблему решает разделение DT на 4000 отдельных репозиториев GitHub?

1. Как пользователь, вы быстрее добираетесь до источников. Вам не нужно использовать какое-то дополнительное приложение, например TypeSearch, для доступа к источникам. В npm у вас есть ссылка непосредственно на необходимое репозиторий для набора текста.

2. Пользователю легче увидеть текущие проблемы и зарегистрировать новые.

   • Вам не нужно искать и фильтровать по одному огромному репо с более чем 2 тыс. Проблем. Что, если репортер забывает следовать правилам именования задач (например, [@types/name-of-package] Issue description )? Вы никогда не найдете нужных проблем.
   • Таким образом, копирование дубликатов в файл не так велико.

3. Как участник вы можете четко отслеживать, сколько проблем у вас есть в вашем репозитории.

   • Вам не нужно (снова) ничего фильтровать, чтобы получить проблемы с вашим конкретным набором текста. Меньше пропустить нужные вопросы.
   • У вас есть четкая мотивация свести к минимуму количество проблем. Количество выпусков больше не является общей ответственностью.
   • Таким образом, менее вероятно, что проблемы, о которых вы забыли, висели там годами .
     Например. 1 страница выпуска за 2013 год, 5 страниц выпуска за 2014 год и так далее.

4. Как член команды TypeScript вы потратили больше времени на улучшение самого машинописного текста (например, поддержку jsdoc), вместо того, чтобы поддерживать / объединять / проверять тысячи типов для множества пакетов npm.
   В зрелой экосистеме это то, что должно делать сообщество.

   • Мы запускаем правила lint для всего репозитория, которые выявляют распространенные ошибки

     Хорошо выпустите пресет lint со всеми рекомендованными правилами и посоветуйте всем участникам использовать последнюю версию этого пресета.

   • Мы находим и исправляем определения с вещами, нарушенными в будущих версиях компилятора.

     Это то, что должны делать участники сообщества. Версия ожидаемого ts-компилятора должна быть четко указана в разделе peerDependency package.json пакета typing-package, чтобы он предупреждал вас, когда вы используете его в неправильной среде.

Вы подходите к этому, исходя из того, что набор текста на самом деле принадлежит кому-либо. Реальность такова, что подавляющее большинство файлов в этом репо были однажды написаны кем-то, кто запустил dts-gen и проверил его с несколькими исправлениями, а затем раз в год исправлялись тремя другими людьми. Здесь нет сильной модели собственности, да и не должно быть.

Что происходит, когда самопровозглашенный «владелец» одного из этих репозиториев решает прекратить его обслуживание? Это происходит постоянно . Как мы отслеживаем, какое репо является «лучшим» в настоящее время? Что произойдет, если они начнут объединять изменения, в результате чего мы не сможем публиковать в NPM?

Это также ухудшает жизнь людей, которые хотят внести исправления. В прошлом году мы добавили параметр типа в файл определения React, который требовал последующих изменений в нескольких сотнях файлов. Кто-нибудь хочет клонировать несколько сотен репозиториев (ох, а какие репозитории?), Чтобы внести широкомасштабные изменения, а затем управлять несколькими сотнями одновременных запросов на вытягивание? Для этого нигде нет даже инструмента.

Как член команды TypeScript вы потратили больше времени на улучшение самого машинописного текста (например, поддержку jsdoc), вместо того, чтобы поддерживать / объединять / проверять тысячи типов для множества пакетов npm. В зрелой экосистеме это то, что должно делать сообщество.

Мы буквально попробовали это, и это не сработало. DT управлялся исключительно сообществом, и это привело к тому, что количество невыполненных запросов на вытягивание составило сотни запросов. С тех пор среднее время слияния PR упало с 2 недель до 4 дней (что является преднамеренным минимумом, чтобы у людей было время взвесить изменения), даже несмотря на то, что объем PR увеличился с ~ 200 в месяц до ~ 1000 в месяц. .

Хорошо, я думаю, что у меня есть ответ на свой первоначальный вопрос «Почему монорепозиторий?»:
Потому что команде TypeScript проще поддерживать определения типов (с учетом зависимостей типов, атомарных обновлений для последующих пакетов, CI, линтинга и т. Д.)

Я все еще думаю, что модель, в которой команда TypeScript играет такую ​​важную роль в поддержке тысяч пакетов, в основном сама по себе, немного странная. Особенно в модульном мире npm, управляемом сообществом.

Но если эта модель вам подходит. Тогда ок: smiley:

@ art-in Я не верю, что намерение состоит в том, чтобы управлять всеми типами из этого репозитория, оно предназначено для управления типами, которые не предоставляются самими пакетами. Если пакет хочет опубликовать типы для своего пакета, он может сделать это прямо в пакете. ОпределенноTyped - это просто место, где типы могут быть агрегированы без согласия разработчика исходного пакета.