Новый способ просмотра данных npm, чтобы определить, от кого мы больше всего зависим.
Реестр npm предоставляет огромное количество полезных открытых данных. Многие люди, в том числе и я, в прошлом проводили достаточно много анализа зависимостей.
В этом анализе я хотел сосредоточиться на активной зависимости и активной поддержке. Я остановился на процессе, в котором я просматриваю выпуски пакетов в течение заданного периода времени. Это дает мне хорошее представление о том, от чего зависят в последнее время, а не исторически, и кто является активным сопровождающим.
Анализ за сентябрь 2019 года дает некоторые интересные результаты, вот 10 лучших сопровождающих:
+----------------+--------+-----+-------+------------+ | OWNER | DEPS | R | RRANK | SCORE | +----------------+--------+-----+-------+------------+ | danez | 502568 | 77 | 0.908 | 456331.744 | | loganfsmyth | 509089 | 59 | 0.883 | 449525.587 | | hzoo | 508653 | 58 | 0.882 | 448631.946 | | existentialism | 461605 | 58 | 0.882 | 407135.61 | | types | 342591 | 505 | 0.988 | 338479.908 | | nicolo-ribaudo | 278943 | 58 | 0.882 | 246027.726 | | fb | 247372 | 87 | 0.918 | 227087.496 | | gaearon | 186342 | 98 | 0.926 | 172552.692 | | jhnns | 221843 | 19 | 0.704 | 156177.472 | | ljharb | 155464 | 79 | 0.91 | 141472.24 | +----------------+--------+-----+-------+------------+
Как видите, первые места по-прежнему принадлежат людям с очень большим количеством проектов, которые зависят от них, но некоторые пользователи, такие как бот types, могут немного подскочить в списке, будучи более активными релизерами, чем их коллеги.
Еще стоит отметить невероятно большое падение с №1 на №10, примерно в 3 раза. Даже в самом верхнем процентиле сопровождающих разница между этими людьми очень велика.
Все четыре верхних места принадлежат babel сопровождающим, и их зависимые числа намного выше, чем у остальных сопровождающих в npm. В то время как типичный анализ поддержки npm показывает много старых зависимостей Node.js и специалистов по сопровождению в первых местах, это говорит о другом и указывает на критическую зависимость экосистем от babel и его сопровождающих.
Но самое интересное для меня то, что этот метод можно использовать для поиска сопровождающих, от которых сильно зависят, но по какой-либо причине они неактивны и нуждаются в поддержке.
Методология
Обычно, когда мы пытаемся количественно определить, «от кого мы зависим», мы смотрим на сеть зависимостей в каждом пакете в npm. Этот метод имеет сильную историческую предвзятость.
Многие пакеты в npm больше не используются, но при таком ранжировании они внесут большой вклад в измерение своих зависимостей.
Поскольку эти старые метрики используются для определения «бремени обслуживающего персонала», это измерение становится все более проблематичным. Например, мой собственный request пакет сильно зависит от исторически, но не так сильно зависит от новых и активно поддерживаемых проектов.
Степень «бремени» сопровождающего пропорциональна тому, сколько времени они фактически тратят на поддержку пакетов. Опять же, request - отличный пример, так как моя нагрузка на обслуживание близка к нулю, поскольку мы фактически устарели этот пакет.
Я хотел попытаться количественно оценить активную зависимость и активное сопровождение как можно точнее с учетом имеющихся данных. Я остановился на процессе, в котором я просматриваю выпуски пакетов в течение заданного периода времени. Это дает мне хорошее представление о том, от чего зависят в последнее время, а не в прошлом.
Затем я нашел количество новых выпусков, связанных с каждым издателем npm. Это дает хорошее представление о том, насколько активен каждый человек. Затем мы можем ранжировать каждого человека от 0 до 1 в зависимости от количества выпусков, которые они сделали за указанный период, что дает нам представление о активности каждого пользователя по сравнению со своими сверстниками.
Затем мы можем «оценить» каждого пользователя, умножив уровень их зависимости на рейтинг их активности.
Мне нравится этот метод оценки, потому что количество проектов, которые активно зависят от человека, обеспечивает потолок для их оценки, и тогда он может уменьшаться только в зависимости от того, насколько активными они были.
Нет идеального анализа. Одна из проблем этого метода сбора заключается в том, что мы не знаем, какие владельцы пакета фактически внесли вклад в выпуск, все они имеют одинаковый вес. Точно так же деп - это деп - это деп, у нас нет способа измерить, насколько проект зависит от одной зависимости по сравнению с другой. И, конечно же, поскольку каждый владелец получает кредит за кого-то в зависимости от своего проекта, проекту с 7 владельцами дается 7 баллов для этих пользователей по сравнению с 1 баллом для одного проекта сопровождающего.
Это всего лишь анализ мелких зависимостей, зависимостей верхнего уровня в каждом выпуске, а не базовой сети зависимостей. Однако, поскольку этот метод полагается на выпуски в заданном временном интервале, он делает менее необходимым глубокий анализ зависимостей, поскольку сеть депо также освобождает в временном интервале если промежуточная зависимость активно поддерживается . Опять же, этот метод имеет тенденцию склоняться к бремени активного обслуживания, а не к исторической зависимости.
Примечание. Еще одним важным аспектом анализа является то, что мы удаляем всех пользователей, которые были либо неактивны, либо от них не зависели. Это означает, что когда мы оцениваем пользователя по отношению к его коллегам, мы оцениваем его только по отношению к активным сопровождающим.
Необработанные данные доступны в общей электронной таблице Google. Обработка данных также общедоступна в собственном репо и построена на минимизированном наборе данных npm, который обновляется ежечасно, а также публично. доступный.
