Moiva.io V3: универсальный инструмент для оценки, обнаружения и сравнения программного обеспечения

Привет, Алексей здесь. У меня есть несколько захватывающих новостей для вас!

Я переписал Moiva.io С нуля и сделал его универсальным и гибким инструментом, чтобы подать в вкус каждого разработчика программного обеспечения, будь то JavaScript, Python или [поместите ваш любимый язык здесь] разработчика.

Эта статья отмечает третий крупный выпуск Moiva.

Что нового (короче)

Возможность поиска и получать данные для любого репозитория GitHub в дополнение к поиску и сравнению пакетов NPM.
возможность принести (относительно легко) Поиск, предложения и возможности сравнения с системами управления пакетами других языков программирования, таких как Maven (Java), Pip (Python), или Packagist (PHP).
И последнее, но не менее важное: Moiva получила с открытым исходным кодом Анкет

Почему я это сделал

Сначала я хотел сосредоточиться на экосистеме JavaScript, сделав пакеты NPM первоклассных граждан в Moiva.io.

Цель состояла в том, чтобы предоставить разработчикам хороший инструмент для оценки и сравнения пакетов NPM в разных измерениях – популярность, обслуживание, безопасность и т. Д.

Но очень скоро я понял, что есть много проектов, связанных с JavaScript, в которых нет опубликованных пакетов NPM.

Подумайте, например, такие рамки, как Метеор Анкет

Moiva.io потенциально может быть полезна для оценки этих проектов благодаря диаграммах Github (вкладчики, проблемы, частота коммитов и т. Д.), Но функциональность поиска ограничивалась только пакетами NPM, и все было построено вокруг концепции пакетов NPM Анкет

С другой стороны, если Moiva будет открыт для поиска, оценки и сравнения любой Проект GitHub, он по существу преобразует Moiva в универсальный инструмент и сделает его полезным для многих других разработчиков.

Поэтому я убедился, что Moiva должна стать более универсальной и гибкой, мне просто нужно придумать хорошую гармоничную концепцию того, как она должна выглядеть, работать и как ее реализовать.

Ага момент

Вначале идея поддержки GitHub выглядела смутным и размытым. У меня не было хорошей идеи, как собрать существующую функциональность для пакетов NPM и нового для репозитории GitHub.

Я мог бы реализовать отдельные страницы для NPM и GitHub, но это было не идеально. Оба имеют много общего при сравнении проектов JavaScript.

Тогда Ага Наступил момент – все стало ясно, я понял, как собрать разные вещи, и с тех пор я был неудержимым.

Вот суть решения.

Один поиск всех

Один и тот же целевой поле поиска можно использовать для поиска как пакетов NPM, так и репозитории GitHub. Это может быть легко достигнуто с помощью модификаторов поиска (префиксы).

Поиск по умолчанию предназначен для GitHub.

Поиск префикс с n: для пакетов NPM.

Что мне нравится в этом решении, так это то, что в будущем его можно легко расширить для поиска других вещей.

Показать только соответствующие диаграммы

Если пользователь выбирает только репозитории GitHub без связанных пакетов NPM, то мы можем просто скрыть диаграммы, связанные с NPM. Нет причин показать их.

Это похоже на то, как работают диаграммы использования Techradar и разработчиков и разработчики – они показаны только тогда, когда есть данные для выбранных пакетов NPM.

В то же время, если пользователь выбирает сочетание проектов NPM и GitHub, мы покажем диаграммы, связанные с NPM для выбранных пакетов NPM.

Как насчет URL

Каждое сравнение, которое пользователь делает в Moiva, должно быть легко воспроизводимым с помощью URL.

Это означает, что Moiva должна быть в состоянии вывести из URL, какую информацию загружать, что поместить в сравнение.

Когда пакеты NPM были единственными гражданами в мире Moiva, задача была легко решена – выбранные имена пакетов NPM были перечислены в параметре запроса: https://moiva.io/?compare=react+svelte+vue Анкет

Наличие двух типов граждан, NPM и GitHub, где один зависит от другого, немного усложняет ситуацию. Более того, мы хотим построить будущее решение, которое может включать другие типы граждан, таких как PIP и Maven.

GitHub имеет более широкую область, чем NPM, и моей первой идеей было заменить идентификаторы URL NPM на идентификаторы GitHub. Но есть 2 проблемы с этим:

Не ясно, как вывести пакет NPM из репозитория GitHub. По крайней мере, я не мог найти решение для этого.
Один репо github может быть источником нескольких пакетов NPM. Нет соединения 1: 1.

Это приводит меня к выводу, что GitHub и NPM должны быть направлены отдельно в URL.

Поэтому я просто решил иметь отдельные параметры запроса: https://moiva.io/?npm=svelte+vue&github=meteor/meteor Анкет

Примирение GitHub и NPM

Представьте себе две ситуации:

Пользователь выбирает Vue в качестве пакета NPM.
Пользователь выбирает Vue в качестве репозитория GitHub.

В первой ситуации Moiva показывают, что данные, связанные с NPM, и диаграммы, такие как загрузки NPM. Во второй ситуации это не так.

Но справедливо ли это? Скорее всего, пользователь рассчитывает увидеть один и тот же набор информации в обоих случаях, верно?

Можем ли мы каким -то образом получить информацию о пакете NPM из репозитория GitHub? Если да, то мы могли бы показать данные NPM для выбранного репозитория GitHub.

Оказывается, мы можем использовать Moiva Catalog который был создан для реализации механизма предложений. Для каждого перечисленного репозитория GitHub мы можем добавить имя пакета NPM, если он есть. Это означает, что мы можем решить проблему примирения для элементов, перечисленных в каталоге. И я думаю, что это достаточно хорошее решение, с помощью которого мы можем охватить самые популярные библиотеки.

Нам просто нужно позаботиться о некоторых деталях и краевых случаях.

Если репозиторий имеет пакет NPM, но этот пакет является лишь одним из «побочных продуктов» репо, то, вероятно, не имеет смысла показывать данные пакета NPM при выборе репозитория. Чтобы решить эту проблему, дополнительный флаг isnpmcoreartifact В каталоге можно использовать для указания «роли» пакета NPM.
Если мы успешно выведем данные NPM из репозитория GitHub, это означает, что мы по существу отображаем одну и ту же информацию как для NPM, так и для GitHub и имеем разные идентификаторы URL для одной и той же страницы. Это не хорошо, особенно с точки зрения SEO. Поэтому я решил использовать имя пакета NPM в качестве идентификатора URL -адреса в таких случаях. Попробуйте загрузку https://moiva.io/?github=vuejs/vue URL и посмотрите, что произойдет; =)

Модель данных

Я упомянул лишь несколько проблем, которые мне пришлось решить. Были, конечно, многие другие, такие как обработка дублирования, псевдонимы, SEO и т. Д.

Большинство проблем получили прямое решение после того, как я внедрил правильную модель данных – я придумал новую абстракцию, называемую «библиотекой» и предоставил ей определенные свойства и поведение.

Если вам интересно, вы можете проверить Repository’s Readme Для получения более подробной информации о концепции библиотеки.

Что дальше

Я ясно вижу огромный потенциал для Moiva.io стать действительно полезным инструментом для многих разработчиков.

Он может расти и стать лучше в разных направлениях. Я упомяну несколько из них, которые выглядят для меня самым важным:

Включите поиск/предложение/сравнение для пакетных систем большего количества языков (Maven, PIP и т. Д.).
Добавьте более полезные диаграммы и данные, как общие, так и в специфике для языка/пакета.
Значительно улучшить систему предложений альтернатив. В настоящее время он основан на Moiva Catalog и нужно много данных, которые можно поместить туда. Я вижу способ, как сообщество может помочь и внести свой вклад.

Я надеюсь, что я не тратил ваше время, и вы нашли чтение и сам проект интересным.

Эта статья была первоначально опубликована в блоге Moiva https://moiva.io/blog/universal-tool-to-evaluate-discover-compare-software

Оригинал: “https://dev.to/aantipov/moiva-io-v3-a-universal-tool-to-evaluate-discover-and-compare-software-1dhe”