Une permission OIDC dédiée aux dist-tags
Depuis le 30 septembre 2026, npm permet aux configurations de trusted publishing de gérer des dist-tags comme latest, next ou beta avec l’identité OIDC du workflow et des identifiants de courte durée. Jusqu’ici, la publication ou la préparation d’un paquet pouvait déjà passer par le trusted publishing, mais les opérations sur les dist-tags exigeaient encore un jeton npm granulaire. L’annonce officielle détaille ce changement : annonce officielle GitHub
Aucun droit supplémentaire par défaut
La nouvelle permission Allow npm dist-tag reste désactivée par défaut, pour les configurations nouvelles comme existantes. Son activation est indépendante de l’autorisation accordée à npm publish. Une configuration limitée au staged publishing peut donc gérer les dist-tags sans obtenir, par ce seul réglage, le droit de publier directement.
L’accès dépend de la correspondance entre l’identité OIDC du workflow et une configuration de paquet autorisant explicitement cette opération. Les usages reposant sur des jetons npm traditionnels ne changent pas. Il ne s’agit donc pas d’une suppression universelle des jetons pour toutes les commandes npm.
Versions et environnements compatibles
La gestion des dist-tags par OIDC requiert npm CLI 11.21.0 ou une version ultérieure de la branche 11, ou npm CLI 12.2.0 ou une version ultérieure de la branche 12. Ce prérequis est distinct du minimum 11.5.1 indiqué pour le trusted publishing général. Une fois la permission activée, la CLI récupère automatiquement l’identité OIDC fournie par l’environnement CI pour les commandes dist-tag. La documentation technique est disponible ici : documentation npm
Au 30 septembre 2026, le trusted publishing documenté couvre GitHub Actions avec les runners hébergés par GitHub, GitLab.com avec les runners partagés et CircleCI cloud. Les runners auto-hébergés ne sont pas pris en charge à cette date. La lecture des tags d’un paquet privé exige également la permission Allow npm dist-tag, tandis que les tags publics restent consultables sans authentification. Les autres commandes, notamment install, view et access, conservent leurs méthodes d’authentification habituelles.
