Показать HN: Shouldiuse.dev – Проверка работоспособности зависимостей программного обеспечения ( shouldiuse.dev ) Как инженеры-программисты, мы часто сталкиваемся с необходимостью принятия решения: писать код самостоятельно или добавить существующую библиотеку, которая сделает это за нас.
Нравится нам это или нет — мы рано или поздно добавляем зависимости. И, пожалуй, хорошей практикой является проверка новой зависимости заранее: поддерживается ли она? Кем? Сколько у нее проблем и сколько из них ошибок? Исправляются ли они? Что в плане? Какова частота релизов и как часто ломаются API?
Одним из наших любимых решений, которые уже существуют для ответа на такие вопросы, является проект OpenSSF Scorecard ( https://github.com/ossf/scorecard ) — мы сами его используем и можем только рекомендовать.
Мы создали shouldiuse.dev на его основе, чтобы сделать результаты доступными в виде веб-сайта, и использовали возможность впервые в профессиональном проекте глубоко погрузиться в программирование с использованием LLM.
Три человека (разработчики и не-разработчики) начали кодировать vibe начальные прототипы, один использовал v0, один использовал lovable и один использовал Cursor. Сначала мы были поражены тем, как быстро мы смогли их сгенерировать и как здорово они выглядели, но вскоре столкнулись с проблемами объединения разных идей, поскольку вокруг летало множество различных веб-фреймворков и версий. Большая часть работы над фронтендом определенно ушла на то, чтобы правильно проработать детали и небольшие адаптации.
Параллельно на бэкенде мы начали писать приложение Go, которое использует библиотеку ossf/scorecard для выполнения множества необходимых нам проверок. Чтобы также поиграться с ИИ на этом конце, мы намеренно активно использовали Copilot и пробовали разные модели и подсказки. Мы также добавили больше метрик к проверке зависимостей, которые мы собираем через API GitHub, и, наконец, генерируем текстовые сводки через OpenAI.
Запрос на формирование окончательной текстовой рекомендации состоит из:
* Заголовок, указывающий роль, возможности и ограничения, а также ожидаемый формат ответа (JSON и никаких списков/маркированных списков) — мы также говорим, что он должен быть критичным, объективным и давать краткие и лаконичные ответы. * Результат проверки оценочной карты * Дополнительные данные, связанные с сообществом * Вопросы, которые отображаются в разделе часто задаваемых вопросов — ответы на них также генерируются LLM.
Поскольку такая проверка подразумевает интенсивное использование API GitHub, мы требуем, чтобы пользователи вводили токен личного доступа GitHub при запросе проверки. Первая проверка репозитория на shouldiuse.dev займет несколько секунд, но затем результаты сохраняются в postgres для более быстрого извлечения в дальнейшем.
На данный момент он работает только для публичных репозиториев GitHub, но мы можем добавить и другие платформы, если возникнет интерес.
Мы также добавили удаленный сервер MCP со встроенной аутентификацией, чтобы вы могли напрямую обращаться к shouldiuse из своей IDE и автоматически проверять новые зависимости каждый раз, когда помощник по кодированию добавляет их, чтобы гарантировать, что в проект добавляются только безопасные зависимости.
То, что начиналось как забавный внутренний эксперимент, быстро удивило нас тем, насколько полезным оно оказалось. Мы не планировали публиковать его, но мы думаем, что это может быть полезно для других разработчиков, и поэтому мы хотели поделиться этим здесь. Любые отзывы приветствуются!
Единственное, что может быть безумнее, чем просьба предоставить персональный токен доступа, — это то, что люди, вероятно, это делают.
Здесь следует сделать серьезное предупреждение: все основано на эвристике, а эвристика может быть ошибочной (в лучшем случае) или злонамеренно измененной (в худшем).
Хотелось бы, чтобы компании использовали более простой подход: перестаньте посредничать в своих взаимодействиях с открытым исходным кодом через посредников и работайте напрямую с вашими апстримами. Вы можете обнаружить, что у вас слишком много людей, с которыми нужно работать, и в этом случае вы обнажаете проблему, а не скрываете ее метриками и политиками.
Пробовал публичный репозиторий, но он запросил личный токен доступа? Нет, спасибо. В остальном отличная идея, но зачем мне давать личный токен доступа для чего-то, что общедоступно, это действительно не внушает доверия.
Спасибо, scusku, персональный токен доступа не имеет никаких дополнительных разрешений, нам просто нужно избежать ограничения скорости.
Почему бы не использовать свой собственный токен доступа?
Source: news.ycombinator.com