pnpm 11.8.0 est sorti le 18 juin 2026, trois jours après 11.7.0, la version qui ajoutait --frozen-store, la délégation de résolution à pacquet et un correctif de traversal de chemin dans le lockfile. Là où la 11.7 portait sur les installations reproductibles et en lecture seule, la 11.8 vise l'observabilité et le reporting de chaîne d'approvisionnement : un mode dry-run qui reproduit enfin npm, un format de package map Node.js qui alimente les expériences de résolution du runtime, et deux améliorations CycloneDX SBOM qui rendent pnpm sbom utilisable pour de vrais workflows de conformité. On trouve aussi un second avis de traversal de chemin, cette fois dans configDependencies, et un correctif macOS Gatekeeper qui agaçait les utilisateurs de modules natifs depuis un moment.
pnpm install --dry-run : la fonctionnalité que npm avait et pas pnpm
L'ajout principal est --dry-run pour pnpm install. Il exécute une résolution complète des dépendances contre les manifestes courants et affiche ce qu'une installation ajouterait, supprimerait ou modifierait, puis n'écrit rien : ni pnpm-lock.yaml, ni node_modules, ni mutation du store. Il quitte toujours avec le code 0, ce qui correspond à la sémantique de npm install --dry-run et clôture l'issue #7340, ouverte depuis 2022.
L'usage pratique est la CI et la revue de code : une PR qui monte une dépendance ou change une entrée de catalogue peut lancer pnpm install --dry-run pour exposer le diff transitif complet, y compris les avertissements de peer et les approbations de build-script, sans toucher au répertoire de travail. Comme la résolution de pnpm est déjà rapide, le coût est une passe de résolution sans écriture sur le système de fichiers. Le code de sortie est volontairement toujours 0 pour que le drapeau puisse s'insérer dans une étape d'installation existante sans faire passer un pipeline au rouge sur un diff bénin.
Package maps Node.js dans node_modules/.package-map.json
La 11.8 peut désormais générer un node_modules/.package-map.json lors des installations isolated (par défaut) et hoisted. Deux paramètres contrôlent le comportement :
node-experimental-package-map: quand il est activé, pnpm injecte la carte générée dans les environnements de script Node.js qu'il gère, afin que le runtime puisse consulter une disposition de paquets précalculée au lieu de parcourirnode_modulesau démarrage.node-package-map-type: choisit entre une cartestandardet une carteloose, au prix d'un compromis entre rigueur et compatibilité.
C'est une plomberie précoce pour la réforme de résolution de paquets de Node, où un fichier de carte déclaratif pourrait remplacer la résolution implicite et pilotée par le système de fichiers que chaque gestionnaire de paquets doit actuellement contourner. Le fait que pnpm génère la carte signifie que les projets qui l'activent obtiennent une description de disposition cohérente, qu'ils utilisent le linker isolated ou hoisted. Le nom du paramètre (node-experimental-package-map) signale que le format n'est pas encore stable.
SBOM : le scope des devDependencies et la génération par paquet
Les deux changements SBOM de la 11.8 ciblent l'écart entre un arbre de dépendances et ce dont un consommateur CycloneDX peut réellement déduire.
Premièrement, pnpm sbom marque désormais les composants accessibles uniquement via les devDependencies avec le scope CycloneDX scope: "excluded" et la propriété cdx:npm:package:development. Le scope excluded est la façon CycloneDX de documenter « l'usage d'un composant à des fins de test et autres usages non runtime », ce qui correspond exactement à une devDependency. La propriété reproduit le marqueur qu'émet @cyclonedx/cyclonedx-npm, donc les consommateurs modernes (basés sur le scope) et existants (basés sur la propriété) le récupèrent tous les deux. Les composants accessibles au runtime, y compris les optionalDependencies installées, omettent le scope et valent required par défaut.
Deuxièmement, la génération de SBOM par paquet arrive via deux drapeaux :
--out out/%s.cdx.jsonécrit un document CycloneDX par paquet du workspace dans des fichiers individuels.--splitémet du NDJSON sur stdout, un paquet par ligne.
Quand --filter sélectionne un seul paquet, le composant racine de la SBOM utilise désormais les métadonnées de ce paquet. Les inter-dépendances du workspace déclarées via le protocole workspace:, ainsi que leurs dépendances transitives, sont incluses pour qu'une SBOM par paquet soit autonome. L'auteur, le dépôt et la licence reviennent au manifeste racine quand le paquet ne les définit pas. Pour un monorepo qui doit livrer une SBOM par bibliothèque publiée, c'est la différence entre post-traiter un document géant et obtenir des artefacts par paquet directement depuis l'outil d'installation.
Traversal de chemin sur les configDependencies (GHSA-qrv3-253h-g69c)
La 11.8 corrige un second avis de traversal de chemin, distinct du correctif d'alias de lockfile en 11.7 et de la traversal Windows d'esbuild 0.28.1 qui avait surfaced dans un autre outil. Avant la 11.8, un lockfile dont les configDependencies contenaient un nom (par exemple ../../PWNED) ou une version (par exemple ../../../PWNED) de type traversal pouvait provoquer une écriture de liens symboliques ou de fichiers en dehors de node_modules/.pnpm-config et du store lors d'un pnpm install.
Le correctif valide les noms et versions des configDependencies avant qu'ils ne soient utilisés pour construire des chemins. Les noms doivent désormais être des noms de paquet npm valides et les versions des chaînes semver exactes. La même validation s'applique aux sous-dépendances optionnelles des configDependencies et au format legacy des manifestes de workspace, avant toute écriture du lockfile. Comme la porte de vérification de la 11.7, c'est une défense en profondeur : un projet qui fait déjà confiance à sa source de lockfile en bénéficie quand même, car la vérification protège contre la corruption partielle et contre les bugs dans le générateur de lockfile lui-même. Voir GHSA-qrv3-253h-g69c.
macOS Gatekeeper ne bloque plus les binaires natifs
Un correctif plus discret mais largement ressenti : quand pnpm importe des fichiers depuis son store à adressage de contenu vers node_modules, macOS préserve les attributs étendus, dont com.apple.quarantine. Si cet xattr était présent sur un blob du store (par exemple, il a d'abord été écrit sous une application Gatekeeper-activée comme un client Git), il se propageait vers node_modules, et Gatekeeper bloquait le binaire natif au chargement même si pnpm avait déjà vérifié l'intégrité du fichier contre le lockfile.
Après l'import d'un paquet, la 11.8 retire désormais com.apple.quarantine des binaires natifs (.node, .dylib, .so), reproduisant le comportement de Homebrew qui retire la quarantaine des téléchargements vérifiés. Le nettoyage est réservé à macOS, s'exécute en un seul appel xattr groupé par paquet, se limite aux binaires natifs pour que les autres fichiers restent intacts, et est non bloquant. Il corrige #11056.
Autres correctifs à connaître
pnpm run --no-bail quitte désormais avec un code non nul quand un script exécuté échoue, tout en continuant à exécuter tous les scripts correspondants jusqu'au bout. Cela clôture l'issue #8013 : les exécutions --no-bail non récursives quittaient toujours avec 0 même en cas d'échec, ce qui était incohérent avec les exécutions récursives qui échouaient déjà à la fin.
pnpm view sans nom de paquet cherche désormais vers le haut le manifeste de projet le plus proche (package.json, package.yaml ou package.json5) et utilise son champ name, remplaçant la dépendance find-up par le module empathic, plus rapide. Plusieurs bugs de correction du lockfile arrivent aussi : les installations incrémentales ne conservent plus les dépendances transitives dupliquées qu'une installation fraîche n'aurait pas produites (#5108), optimisticRepeatInstall ne signale plus « Already up to date » quand seul le lockfile a changé (#12100), et les overrides de catalogue qui se résolvent via un catalogue restent synchronisés avec le catalogue pendant pnpm update. pnpm version --recursive respecte désormais le filtre de workspace au lieu de monter chaque paquet (#11348). La sortie du reporter pour pnpm store et pnpm config va désormais sur stderr, pour que des scripts comme PNPM_STORE=$(pnpm store path) ne capturent plus d'avertissements dans leur résultat.
Mise à niveau
pnpm 11.8.0 requiert Node.js 22.13 ou supérieur, la même ligne de base que la 11.7. Le format du lockfile est inchangé, donc un npm install -g pnpm@latest (ou corepack prepare pnpm@latest --activate) suivi d'un pnpm install constitue le chemin complet de mise à niveau. Les nouveaux drapeaux sont tous opt-in, et la validation des configDependencies ne rejette que des entrées qui n'ont jamais été des noms de paquet valides.
