npm расширил возможности Trusted Publishing: доверенной конфигурации теперь можно отдельно разрешить управление dist-tag с помощью короткоживущих учётных данных OIDC. Обновление закрывает пробел в автоматизации релизов, из-за которого разработчикам приходилось сохранять постоянный токен даже после перехода на публикацию пакетов без токенов.
О новой возможности GitHub сообщил 30 сентября 2026 года. Разрешение включается вручную и не предоставляется существующим конфигурациям автоматически.
Какой пробел оставался в Trusted Publishing
Trusted Publishing позволяет связать npm-пакет с доверенным CI/CD-окружением и получать временные учётные данные через OpenID Connect. В случае GitHub Actions workflow подтверждает свою идентичность без сохранённого в репозитории npm-токена. Общий принцип работы OIDC в GitHub Actions описан в документации GitHub.
До обновления такой механизм охватывал публикацию и staging пакетов, но не операции с dist-tag. Поэтому workflow мог успешно выпустить новую версию, однако для последующего переноса указателя `latest`, `next` или `beta` ему всё ещё требовался отдельный granular access token.
Это было особенно заметно в многоэтапных релизных схемах. Например, команда могла сначала опубликовать сборку под предварительным тегом, провести дополнительные проверки, а затем назначить той же версии тег `latest`. Второй этап нельзя было полностью перевести на Trusted Publishing, если он менял dist-tag.
Теперь соответствующее право может быть добавлено к доверенной конфигурации. По данным GitHub, операции с тегами в этом случае выполняются с использованием короткоживущих OIDC-учётных данных, а постоянный токен, хранившийся только ради dist-tag, становится не нужен.
Разрешение сделано опциональным
Новая возможность работает по принципу явного согласия. В настройках Trusted Publishing нужного npm-пакета владелец должен выбрать конкретную конфигурацию и включить параметр `Allow npm dist-tag`.
Такой подход разделяет право на публикацию и право изменять каналы распространения. Конфигурация, выпускающая пакет, не получает возможность автоматически переназначать `latest` или другие теги, если администратор пакета не разрешил это отдельно.
Dist-tag в npm представляет собой понятный человеку указатель на определённую версию пакета. При обычной установке без номера версии npm ориентируется на тег `latest`, тогда как `next`, `beta` и другие названия часто используются для предварительных или параллельных веток релизов. Поведение этих указателей и команды для работы с ними описаны в справке npm CLI.
Изменение тега не создаёт новую версию пакета и не заменяет уже опубликованный архив. Оно меняет версию, на которую указывает выбранный канал. Поэтому доступ к dist-tag способен влиять на то, какую сборку пользователи получат при установке пакета без явно заданной версии.
Что изменится в релизных workflow
Основной эффект обновления — возможность убрать долгоживущий секрет из тех workflow, где он оставался только для команд управления тегами. Это сокращает число постоянных учётных данных, которые приходится хранить, выдавать отдельным процессам и регулярно заменять.
Практически изменение подходит для нескольких распространённых сценариев:
- продвижение проверенной версии из предварительного канала в `latest`;
- обновление указателей `next` и `beta`;
- возврат dist-tag на предыдущую опубликованную версию после проблемного релиза;
- разделение прав между workflow публикации и workflow продвижения релиза.
При этом анонс не означает, что npm автоматически удалит ранее созданные токены или перепишет существующие CI/CD-файлы. Если workflow передаёт `NPM_TOKEN` другим шагам либо использует его для операций, не покрываемых Trusted Publishing, перед удалением секрета нужно проверить весь релизный процесс.
Не следует также считать, что новая настройка распространяется на любые реестры пакетов. Сообщение касается Trusted Publishing для npm и операций npm dist-tag. Для GitHub Packages, частных сторонних реестров или собственных прокси могут действовать другие правила аутентификации.
Что проверить мейнтейнерам
Сначала стоит определить, выполняет ли релизный workflow команды, меняющие dist-tag после публикации. Наличие `npm dist-tag add`, `npm dist-tag rm` или публикации с параметром `—tag` указывает на то, что пайплайн использует каналы распространения, но конкретные права и поведение следует проверить на тестовом выпуске.
Далее мейнтейнеру нужно:
Открыть настройки Trusted Publishing у соответствующего пакета в npm.
Найти конфигурацию, связанную с нужным репозиторием и workflow.
3. Включить `Allow npm dist-tag` только для процесса, которому действительно требуется это право.
4. Запустить тестовый релиз с предварительным тегом, не затрагивая стабильный канал.
5. Убедиться, что workflow может изменить нужный dist-tag без постоянного npm-токена.
6. Лишь после проверки удалить неиспользуемый секрет из CI/CD и связанных окружений.
Общая документация по настройке доверенных издателей доступна в руководстве npm по Trusted Publishing. Там же следует сверять поддерживаемые CI/CD-провайдеры, требования к конфигурации и ограничения механизма.
Если один workflow только публикует версии, а другой переводит их в стабильный канал, новое разрешение разумно выдать лишь второму. Это сохраняет разделение обязанностей и не расширяет доступ там, где управление dist-tag не требуется.
