pnpm 12 passe en Rust : plus rapide, même API

Pourquoi c'est vraiment un rewrite, pas une rustification cosmétique

pnpm a été entièrement réécrit en Rust. Le gain de performance n'est pas du marketing : sur les espaces de travail chargés de cycles de dépendances (courant en monorepos), la résolution est 2–3× plus rapide et consomme 25% moins de mémoire. Les lockfiles deviennent aussi 25% plus petits.

Ce qui change vraiment : pnpm 12 résout les cycles de dépendances de façon canonique. Avant, l'ordre dans lequel on revenait à une dépendance cyclique changeait la signature du lockfile. Maintenant, c'est une fonction pure : mêmes dépendances, même ordre, byte-identical. Ça semble anecdotique, mais ça rend les builds déterministes et empêche les faux conflits en CI.

Les trois changements qui vont te toucher

1. Les binaires globaux comprennent le projet

Tu as Node.js 20 d'installé en global, mais ton projet épingle Node.js 22 ? Avant pnpm 12, tu devais jongler avec des hooks shell peu élégants ou nvm.

Maintenant, node obéit au .pnpmrc du projet. Idem pour deno et bun. Et c'est signé : une version stable de Node.js est vérifiée contre les signatures de l'équipe de publication ; tout le reste (prépublications, packages personnalisés) demande une validation de confiance une fois, puis la mémorise par machine et par projet.

Tu peux contourner ça avec PNPM_SHIM_BYPASS=1 si tu dois.

2. pnpm récupère les gestionnaires manquants

Tu clones un dépôt Yarn, mais tu as juste pnpm ? pnpm 12 télécharge Yarn depuis le registre authentifié, le lance, puis l'oublie. Zéro pollution globale.

Ça marche aussi avec pnx (en usage ponctuel) : pnx yarn@4 install, pnx npm@11 ci, etc. Et les shims : pnpm shim add yarn lie une yarn qui obéit à la version du projet.

3. Registry revisions : correctif sans rebump de version

Un package a une faille ? Au lieu de publier 1.2.3-patch ou attendre une mineure, le registre peut servir un artefact remplacé pour la même version, identifié par son SHA-512. pnpm l'enregistre dans le lockfile :

packages:
  lodash@4.17.21:
    resolution: integrity: sha512-...
    revision: 1

Les dépendances et surcharges peuvent épingler une révision explicitement : lodash@4.17.21+r1. Et pnpm update --patches rafraîchit les artefacts sans toucher les numéros de version.

Les points moins visibles mais utiles

• ▸

  Dépendances git plus cohérentes : github:owner/repo, owner/repo, git+https://…, git+ssh://… passent tous par HTTPS canonique sauf si tu configures git pour le SSH. Le lockfile n'enregistre jamais une URL SSH pour GitHub/GitLab/Bitbucket. Les hôtes inconnus conservent leur URL intacte.

• ▸

  Fautes de frappe détectées dans pnpm-workspace.yaml : Tu oublies une lettre dans minimumReleaseAge ? pnpm le signale maintenant, avec une suggestion. Sur une version épinglée, ça échoue (ERR_PNPM_UNRECOGNIZED_WORKSPACE_SETTINGS) ; ailleurs, c'est un avertissement.

• ▸

  Liens durs avant clone sur Linux : Sur btrfs, un lien dur est plus rapide qu'un reflink (clone). pnpm 12 le passe en priorité sur Linux. ext4 était déjà lien-dur en premier. macOS garde le clone en premier (APFS clonefile).

• ▸

  engineStrict regarde la bordure, pas le sous-arbre : Une incompatibilité de moteur remonte maintenant même si elle vient d'une optionalDependencies. pnpm 11 n'enregistrait qu'une alerte ; pnpm 12 échoue.

Comment l'installer

Le tag latest pointe toujours pnpm 11 (compatibilité). Pour la version 12 :

pnpm self-update next-12

Ou pnpm init dans un nouveau projet : ça épingle maintenant la version de pnpm la plus récente (pas juste celle qui a lancé init), donc zéro dérive en héritage.

Homebrew, winget, Scoop, Chocolatey ne proposent pas encore pnpm 12. Les autres chemins d'installation (npm, binaire autonome) fonctionnent.