20 октября 2026 года GitHub объявил о поддержке npm 12, pnpm 11 и 12, а также Bun 1.4 в Dependabot. Команды могут переходить на эти версии менеджеров пакетов и сохранять автоматические предложения по обновлению зависимостей. На Mentoring.digital разбираем, что проверить в репозитории перед таким переходом.
Коротко: новые версии уже поддерживаются на github.com. Для GitHub Enterprise Server поддержка заявлена в версии 3.24. Сам переход на другой менеджер пакетов, проверка lock-файла и решение о слиянии обновлений остаются задачами команды.
Что изменилось в поддержке Dependabot
Dependabot следит за зависимостями проекта и создаёт pull request с обновлениями. Новость касается совместимости с конкретными версиями инструментов: npm 12, pnpm 11, pnpm 12 и Bun 1.4. Это полезно, если переход на новый менеджер откладывали до появления поддержки в автоматизации репозитория.
Различайте облачный GitHub и собственную установку Enterprise Server. Анонс говорит о доступности для всех пользователей github.com, но для серверной поставки называет 3.24. Наличие функции в облаке само по себе не подтверждает её наличие в установленной у компании версии GHES.
Какие настройки и lock-файлы проверить
В конфигурации Dependabot npm и pnpm относятся к экосистеме npm, а для Bun используется bun. У Bun поддерживается текстовый bun.lock; старый бинарный bun.lockb не подходит. Поэтому смена номера версии инструмента не заменяет проверку файлов в самом репозитории.
Проверьте также каталог манифеста и расписание в .github/dependabot.yml. Если проект использует закрытые реестры, Dependabot должен иметь доступ к ним. Иначе причина неудачного обновления может находиться в правах на зависимости, а не в новой версии npm или pnpm.
На момент подготовки материала таблица поддерживаемых экосистем в документации ещё перечисляла предыдущие версии npm и pnpm. Новые номера подтверждены отдельным анонсом GitHub от 20 октября. При диагностике стоит учитывать эту разницу между страницами документации.
Как проверить переход в своей сборке
- Зафиксируйте используемую версию менеджера пакетов в настройках проекта и CI. Сверьте её с локальной средой разработчика.
- Проведите переход отдельным изменением. Просмотрите diff манифеста и lock-файла, прежде чем смешивать его с обновлением десятков библиотек.
- Проверьте установку зависимостей в чистой среде и запустите существующие тесты и сборку проекта.
- После следующей проверки Dependabot посмотрите журнал задания и созданный pull request. Отдельно оцените изменения транзитивных зависимостей.
Успешная работа бота ещё не означает, что приложение совместимо со всеми предложенными версиями библиотек. Результат обновления оценивают по проверкам самого проекта.
Когда обновление полезно разработчику
Если репозиторий уже использует перечисленные менеджеры, начните с проверки существующего задания Dependabot. Если только планируете миграцию, новость снимает один вопрос совместимости, но не определяет выбор инструмента за вас.
Разобрать манифест, lock-файл и различия окружений можно с наставником по JavaScript. А проверку поведения приложения после обновления библиотек удобно связать с практикой фронтенд-разработки: важно не только получить новый pull request, но и понимать его последствия.
