TL;DR; Текущие поисковые системы npm не очень хороши. Я изучаю алгоритм поиска npm, который дает меньше очков за популярность и больше за последовательность коммитов, релизов и ответов в вопросах/дискуссиях. Таким образом я хочу: 1) сэкономить много времени разработчиков, 2) дать видимость добросовестным разработчикам, которые не продвигают свою работу, 3) и многое другое 👇.
Проблема с поиском хорошего пакета npm
У меня постоянно возникают проблемы с поиском хороших пакетов npm:
npms.io — самый эффективный алгоритм для меня. Однако иногда он работает медленно, иногда я получаю ошибку и никаких результатов. Некоторые проверки больше не работают — это приводит к тому, что старые пакеты имеют более высокие оценки, поскольку индекс обновляется только при публикации новой версии. Если вы просмотрите реализацию, то обнаружите, что большая часть рейтинга определяется некоторыми вещами, которые не очень хорошо соотносятся с тем, насколько хороша библиотека 1. Все это напоминает мне Bogus rankings damage what they ranking. Особенно если те, кого ранжируют, подыгрывают им.
Поиск по npmjs.com — это плохо. Например, одна из моих библиотек, которая находится на первом месте на npms.io, занимает 13-е место на npmjs.com. Эта библиотека — самый скачиваемый хук localStorage, и у меня были постоянные коммиты и релизы в течение последних 2 лет. Я не знаю, что случилось с npm Blog Archive: Лучший поиск здесь!
Другие. У меня есть надежды на будущее socket.dev — он часто дает хорошие результаты. Однако UX все еще имеет некоторые проблемы, и иногда результаты не оптимальны. Качество поиска на libraries.io спорадическое. Я также использую поиск GitHub и Google.
В настоящее время я использую приведенный ниже сценарий bash для поиска по всем упомянутым местам одновременно:
args=$@
encodedValue=$(node --eval "process.stdout.write(encodeURIComponent("$args"))")
open -a "Google Chrome"
"https://npms.io/search?q=$encodedValue"
"https://socket.dev/search?q=$encodedValue"
"https://github.com/search?l=TypeScript&q=$encodedValue&type=Repositories"
"https://github.com/search?l=JavaScript&q=$encodedValue&type=Repositories"
"https://libraries.io/search?languages=&platforms=NPM&q=$encodedValue"
"https://www.google.com/search?q=site:npmjs.org+$encodedValue"
Сценарий bash помогает. Однако этот рабочий процесс отнимает много времени и разочаровывает. Мой опыт таков: Я открываю 10-20 вкладок, закрываю дубликаты, закрываю все неактуальные, закрываю все без какой-либо активности, глубоко погружаюсь в те, что остались. Похоже, что многие другие люди сталкиваются с моей проблемой.
Мое предлагаемое решение
Главный вопрос, который я задаю себе, когда думаю о решении: если вы выложите алгоритм в открытый доступ, и люди будут пытаться оптимизировать его под себя, даст ли это лучшие библиотеки? Вот что я предлагаю:
Коммит, релиз, согласованность ответов. Большинство баллов дается за последовательность релизов, коммитов и ответов на проблемы (исключая не-мейнтейнеров). Чем дольше период постоянства, тем лучше — библиотеки, существующие долгое время и постоянно обновляемые, должны иметь самые высокие баллы. Подумайте об этом, если библиотека постоянно обновляется в течение длительного времени, разве вы не хотите видеть ее независимо от количества загрузок? Больше баллов за равномерно распределенную активность, меньше баллов за случайные всплески. 2. По желанию, если библиотека превышает порог, покажите значок/значок постоянства.
Постоянство аккаунта. Некоторые люди идут прямо на страницу репозиториев Синдре Сорхуса и ищут там. Если человек тратит большое количество времени на внесение вклада, это ценно. Начисляйте баллы постоянным аккаунтам. По желанию, если пользователь превысил определенный порог, покажите значок/нагрудный знак.
Популярность. Вы не можете игнорировать звезды и загрузки. Это важный фактор. Однако дайте ему меньше баллов. Это ключевой аспект данного алгоритма.
Дайте больше баллов. В большинстве поисковых систем есть опция «Сортировать по». Это не работает. Вот почему я предлагаю альтернативную опцию «Дать больше баллов», которая просто переключает величину для определенных критериев. Возможными значениями будут «Repo consistency», «Account consistency» и «Popularity». По умолчанию будет выбрано «Repo consistency». Выбор «Популярность» сделает его более похожим на существующие поисковые системы.
Исключить ботов. Деятельность ботов должна быть исключена, иначе поиск, вероятно, станет намного хуже. Кроме того, это открывает возможность для легких манипуляций. Например, версия, созданная ботом, вообще не должна учитываться. Аналогично тому, как работает страница вклада в репозиторий на GitHub.
Возможный подводный камень в этой идее
Большая часть репозиториев будет иметь низкий рейтинг согласованности. Для учета этого может потребоваться хороший запасной вариант. Я не уверен, что популярность — достаточно хороший запасной вариант.
Возможно ли, что нужны странные и мнительные оценки, используемые другими поисковыми системами? — Я бы поставил на «нет», но я очень осторожен в этом предположении.
Что я сделал, чтобы продвинуть эту идею.
Я связался с Algolia, и они предоставили мне доступ к своему npm-индексу. Я могу использовать его для базовой реализации моей идеи, потому что он включает в себя историю всех релизов. Кроме того, API возвращает отсортированные результаты поиска, которые можно использовать как запасной вариант или базовый показатель. Не уверен, что этого будет достаточно для получения стабильно лучших результатов по сравнению с другими поисковыми системами.
Я создал новое обсуждение в репозитории npm/feedback, чтобы поделиться своей идеей. Я также упомянул свою идею в соответствующих обсуждениях: npm scores, Weird search behavior with stats, и Improve search functionality on npmjs.com.
Если вы являетесь человеком, который может продвинуть эту идею, пожалуйста, напишите мне.
Почему я написал эту статью
Сначала я хотел, чтобы поиск был лучше. Однако после изучения и исследования темы он мне стал больше нравиться за те возможности, которые он может создать:
- сэкономить много времени разработчиков 3
- позволить признать неволевых, но добросовестных разработчиков
- при правильном стимулировании, в теории, качество библиотек и экосистемы в целом должно улучшаться
- в утопическом будущем, когда экосистема улучшится и все больше будут полагаться на open-source, разработчикам open-source будут платить больше.
-
Некоторые из учитываемых вещей для рейтинга: количество значков в readme, длина readme, свойство
.npmignoreилиpackage.jsonвfiles, наличие файлаchangelog.md, использует ли библиотека линтер. Некоторые из проверок реализованы плохо и неверно возвращаютfalse. Алгоритм ранжирования npms.io объяснен -
Я не совсем уверен, как должна выглядеть конкретная реализация. Я думаю, что он должен вычислять равномерность. Что-то вроде этого — Существует ли мера «равномерности» распределения? Однако, если вы понимаете алгоритм/математику, стоящую за этим, напишите мне, чтобы я мог добавить его в статью.
-
Напоминает мне историю Стива Джобса — «Ну, допустим, вы можете сэкономить 10 секунд на времени загрузки. Умножьте это на пять миллионов пользователей, и это 50 миллионов секунд каждый день…