От автора: одним из разочаровывающих аспектов современной экосистемы JavaScript является поддержание всех зависимостей в актуальном состоянии. К счастью, есть автоматизированные инструменты, которые могут справиться с этой неблагодарной задачей.
Если вам нужна веская причина для обновления зависимостей, подумайте о безопасности проекта. Например, в 2019 году была обнаружена критическая уязвимость в lodash, библиотеке, используемой более 4 миллионами проектов на GitHub. Если ваш проект использует lodash, а вы не обновились, у вас может быть проблема безопасности, о которой вы даже не знаете.
Есть и другие причины, в том числе совместимость с другими библиотеками. По умолчанию, когда вы устанавливаете модуль npm, он рекомендует использовать по крайней мере ту версию, которую вы установили. Но это не мешает разработчикам использовать более новые версии по мере их выпуска. Это может вызвать проблемы, если более новая версия содержит критические изменения.
Хотя это полезная практика, обновление зависимостей требует времени и усилий, и это является относительно неблагодарной работой. Другими словами, это идеальная цель для автоматизации!
Есть несколько инструментов, чтобы справиться с этим, в том числе Renovate, Greenkeeper и Dependabot. Эта статья будет посвящена Renovate, потому что он был рекомендован мне коллегой, который не слишком любит инструменты для автоматизации рабочего процесса. В то же время, я также использовал Greenkeeper, и оба они работают примерно одинаково.
Renovate постоянно следит за зависимостями в проекте. Когда выпускается новая версия зависимости, открывается запрос на извлечение (PR) для обновления до последней версии. Затем вы решаете, стоит ли объединять PR. Вы даже можете настроить Renovate на автоматическое объединение определенных типов обновлений!
Уменьшая сложности, связанные с обновлениями зависимостей, Renovate повышает вероятность своевременного их применения.
1. Добавьте приложение Renovate GitHub
Первый шаг — добавить в стек Renovate. Они предлагают интегрированные приложения для GitHub и GitLab, и даже самостоятельный инструмент CLI. Следуйте инструкциям по установке приложения, а затем выберите репозитории Git, которые вы хотите отслеживать.
Renovate проверит хранилище на наличие файла конфигурации менеджера пакетов, например package.json. Если он находит такой, который понимает, он откроет PR для настройки Renovate для вашего проекта.
2. Подтверждение запроса на извлечение
После установки первый PR, который Renovate отправляет в ваш проект, представляет собой минимальный набор изменений для добавления файла конфигурации Renovate.
Вот пример встроенного PR. Описание иллюстрирует, как будет настроен Renovate и чего ожидать после слияния.
Renovate начинает с разумного набора значений по умолчанию. Однако, если вы хотите что-то изменить (например, ограничить, когда или сколько PR он может открывать в день), вы можете отредактировать файл конфигурации Renovate перед объединением в ветви.
С точки зрения того, чего ожидать дальше, наш проект несколько отстал от некоторых версий зависимостей, поэтому он дал мне знать, что откроет несколько PR для их обновления. Вы, вероятно, также увидите нечто подобное.
3. Добавьте бэйдж обновления (необязательно)
При желании вы можете добавить бэйдж в файл README, чтобы посетители знали, что вы обновляете зависимости. Скопируйте и вставьте следующий код в начало файла README, обязательно заменив имя пользователя и имя репо.
[](https://renovatebot.com/)
Когда вы закончите, в верхней части целевой страницы репо должен появиться красивый зеленый бэйдж.
4. Обновите конфигурацию непрерывной интеграции (необязательно)
Если вы используете инструмент непрерывной интеграции (CI), например Travis или Circle CI, вам может потребоваться обновить файл конфигурации CI для работы с ветвями Renovate.
Например, некоторые из наших проектов используют CI для автоматического запуска тестов для PR. Но мы не хотим, чтобы он запускался при каждом коммите для каждой ветви, поэтому он ограничен веткой master.
Чтобы разрешить выполнение тестов для Renovate PR, вам нужно добавить в белый список название ветви Renovate. Вот как это выглядит в файле travis.yml:
# Trigger a push build on master and renovate branches + PRs build on every branches # Avoid double build on PRs (See https://github.com/travis-ci/travis-ci/issues/1147) branches: only: - master - /^renovate.*$/
5. Просмотрите новую партию запросов на извлечение
Вскоре после объединения встроенного PR вы должны увидеть еще несколько открытых PR: один для закрепления зависимостей и, возможно, еще один для обновления устаревших зависимостей.
Ранее я упоминал проблему с npm, позволяющую разработчикам использовать более новые версии зависимостей, чем те, что вам требуются. Закрепление зависимостей означает изменение списка, чтобы востребовать определенную версию.
Закрепление зависимостей — сложная тема, но я бы сказал, что в большинстве случаев это хорошая идея, поскольку это делает более понятным, с какими версиями был протестирован ваш проект.
Renovate может также открыть несколько PR, чтобы обновить зависимости до самых последних версий. Сколько PR вы получаете, зависит от того, насколько актуален ваш проект.
Одна приятная вещь — вам не нужно удалять ветки для всех этих PR. Renovate очистит их через несколько минут после слияния PR!
Как просмотреть запрос на извлечения обновления зависимостей
Принятие решения о слиянии обновлений зависимостей PR будет зависеть от того, как вы хотите протестировать обновление. Если ваш проект представляет собой простой модуль npm с хорошим охватом тестами, вы можете без проблем одобрить, если все тесты пройдут.
С другой стороны, если ваш проект представляет собой более сложное приложение или вы не уверены, что тесты охватывают все, вам может понадобиться проверить ветку и выполнить тестирование вручную.
Для веб-приложений, если вы используете такой инструмент, как Netlify Deploy Previews, у вас может быть среда предварительного просмотра, которая автоматически создается для каждого PR, и в этом случае вы можете просто выполнять тестирование в ней, пока не убедитесь, что все работает.
Полезная информация, которая может вам помочь — это новый номер версии обновленной зависимости. Большинство пакетов npm следуют правилу семантического управления версиями: Major.Minor.Patch. Поэтому обновление с 12.0.0 до 12.0.1 будет выпуском патча, а обновление до 13.0.0 будет основным релизом.
Как правило, младшие и патч-релизы не должны содержать критических изменений, поэтому они с большей вероятностью будут безопасны для слияния. И наоборот, если вы видите изменение основной версии, вы должны быть готовы к более тщательному тестированию.
Что если обновление зависимостей что-то сломает?
Если тесты для PR не пройдены, или если ваше тестирование выявляет проблему, вам нужно найти способ исправить проблему перед слиянием. Вы можете проверить PR-ветку локально, внести необходимые изменения, а затем отправить изменения в ветку.
Renovate PR обычно включает раздел Примечания к релизу, который извлекается из журнала изменений зависимости. Чтение этих заметок может быть полезно при выяснении того, какие изменения вам могут понадобиться.
6. Обновите версию проекта (необязательно)
Нет четкого ответа на вопрос, когда нужно повышать номер версии проекта в отношении обновлений зависимостей. Главное, что нужно учитывать, это то, что номер версии проекта сообщает вашим пользователям, когда что-то изменилось. Ваши пользователи заботятся о каждом обновлении зависимостей?
Например, если вы не выпускаете плагин ESLint, вашим пользователям, скорее всего, все равно, обновится ли версия ESLint, используемая вашим проектом.
Мы придерживаемся принципа: создать основной релиз проекта, если у зависимости есть основной релиз. Если у зависимости есть второстепенный релиз без прерываний, мы обычно не пытаемся обновить номер версии. Это может не иметь смысла для вашего проекта, поэтому проконсультируйтесь со своей командой о том, как вы хотели бы поступить в этом случае.
Поздравляем!
Вы решили трудоемкую проблему с автоматизацией! Получайте удовольствие, наблюдая, как вводятся обновления зависимостей!
Автор: Scott Vandehey
Источник: https://cloudfour.com
Редакция: Команда webformyself.