Faut-il passer de npm à pnpm ?

May 26, 2026 · 5 min read

Vous avez probablement vu pnpm mentionné dans des configurations de monorepo, des fichiers CI et des documentations de frameworks. Peut-être qu’un collègue ne jure que par lui. Mais est-ce que la migration vaut vraiment la friction qu’elle implique pour votre travail frontend quotidien, ou cela résout-il des problèmes que vous n’avez pas encore ?

Voici ce que vous devez vraiment savoir.

Points clés à retenir

pnpm utilise un store adressable par contenu (content-addressable) avec des hard links et des symlinks, éliminant les dépendances fantômes (phantom dependencies) et réduisant l’utilisation du disque sur plusieurs projets.
pnpm 11 poursuit les restrictions sur les scripts de cycle de vie introduites dans pnpm 10, exigeant une approbation explicite via pnpm approve-builds pour réduire les risques liés à la chaîne d’approvisionnement.
Le filtrage des workspaces et le protocole workspace:* font de pnpm un excellent choix pour les monorepos utilisant Turborepo ou Nx.
Épinglez votre gestionnaire de paquets avec le champ packageManager dans package.json et utilisez --frozen-lockfile en CI pour des installations déterministes.
pnpm brille dans les monorepos et les configurations multi-projets ; pour une application à un seul paquet, rester sur npm est souvent suffisant.

Ce qui distingue pnpm de npm

pnpm n’est pas simplement un npm plus rapide. Les véritables différences sont structurelles.

npm crée un répertoire node_modules plat, ce qui signifie que votre code peut accidentellement importer des paquets que vous n’avez jamais déclarés comme dépendances — un problème appelé phantom dependencies. pnpm utilise un store adressable par contenu avec des hard links et des symlinks, de sorte que seules vos dépendances déclarées sont accessibles au niveau racine. Cela rend la résolution des dépendances plus stricte et plus reproductible.

L’autre différence majeure concerne l’utilisation du disque. pnpm stocke chaque version de paquet une seule fois globalement et la lie en hard link dans vos projets. Si vous maintenez plusieurs projets Next.js ou Vite localement, vous ne dupliquez pas des centaines de mégaoctets par projet.

Pour une analyse plus approfondie du modèle de stockage et de l’isolation des dépendances, la comparaison officielle pnpm vs npm vaut le coup d’œil.

pnpm 11 et le virage vers la sécurité

pnpm 11, publié en avril 2026, poursuit une tendance qui se renforce au fil des récentes versions majeures : privilégier la sécurité et le déterminisme plutôt que la vitesse brute.

Le comportement le plus important à connaître avant de migrer : pnpm bloque désormais par défaut les scripts de cycle de vie des dépendances, sauf approbation explicite. C’est le workflow pnpm approve-builds introduit dans pnpm 10. Si vous installez un paquet avec un script postinstall — courant pour les paquets qui compilent des binaires natifs, comme sharp, esbuild ou canvas — l’installation réussira, mais le script ne s’exécutera pas tant que vous ne l’aurez pas approuvé.

Cela surprend les développeurs qui s’attendent à ce que tout fonctionne immédiatement. Exécutez pnpm approve-builds de manière interactive, ou configurez les dépendances de build autorisées dans pnpm-workspace.yaml :

onlyBuiltDependencies:
  - sharp
  - esbuild

C’est un compromis délibéré : plus de friction au départ, moins de mauvaises surprises liées à la chaîne d’approvisionnement par la suite.

Workspaces et outillage pour monorepos

C’est ici que pnpm prend une nette longueur d’avance. Les workspaces npm fonctionnent, mais l’implémentation des workspaces de pnpm est plus ergonomique pour les configurations de grande envergure.

Vous définissez les paquets dans un fichier pnpm-workspace.yaml :

packages:
  - 'apps/*'
  - 'packages/*'

Vous bénéficiez alors de filtres puissants prêts à l’emploi :

pnpm --filter @myapp/ui build
pnpm --filter "...^@myapp/ui" test  # run tests in packages that depend on ui

Pour les équipes utilisant Turborepo ou Nx, le protocole workspace de pnpm (workspace:*) s’intègre parfaitement et garde les dépendances internes explicites.

Épingler les versions avec le champ packageManager

Une étape pratique, que vous utilisiez Corepack ou non : ajoutez un champ packageManager à votre package.json pour indiquer quel gestionnaire de paquets et quelle version votre projet attend.

{
  "packageManager": "pnpm@11.0.0"
}

Corepack peut imposer cela dans les environnements où il est activé, mais même sans Corepack, cela communique clairement l’intention à votre équipe et à votre configuration CI.

Intégration CI avec GitHub Actions

- uses: pnpm/action-setup@v6
  with:
    version: 11
- uses: actions/setup-node@v4
  with:
    node-version: 22
    cache: 'pnpm'
- run: pnpm install --frozen-lockfile

Utilisez toujours --frozen-lockfile en CI. Cela empêche les mutations silencieuses du lockfile et rend les installations déterministes.

La documentation officielle pnpm CI inclut également des exemples pour GitHub Actions, GitLab CI, CircleCI, Azure Pipelines et Bitbucket Pipelines.

Quand la migration en vaut la peine

pnpm prend tout son sens si vous travaillez dans un monorepo, gérez de nombreux projets locaux, ou souhaitez une isolation des dépendances plus stricte par défaut. Le modèle de sécurité pnpm approve-builds est réellement utile pour les équipes soucieuses de l’hygiène de leur chaîne d’approvisionnement.

Si vous maintenez une application à un seul paquet et que npm fonctionne bien, la friction liée à la migration n’en vaut probablement pas la peine. Les workspaces npm sont suffisamment matures pour des configurations simples, et le standard de facto de l’écosystème conserve une réelle valeur.

Conclusion

La réponse honnête : essayez d’abord pnpm sur un nouveau projet. La surface des commandes est quasiment identique, le lockfile est lisible, et la plupart des frameworks frontend — y compris Next.js, Vite et Astro — le prennent en charge sans configuration supplémentaire. Si la rigueur et les économies d’espace disque s’accordent avec votre workflow, la décision de l’étendre à des projets existants devient bien plus simple.

FAQ

Généralement oui. Supprimez node_modules et package-lock.json, puis exécutez pnpm import pour convertir votre lockfile, suivi de pnpm install. Surveillez les dépendances fantômes sur lesquelles votre code aurait pu s'appuyer grâce au layout plat de npm — pnpm les fera apparaître sous forme d'imports manquants, que vous corrigez en les ajoutant explicitement à package.json.

approve-builds est une liste blanche de paquets autorisés à exécuter des scripts de cycle de vie. Vous pouvez désactiver entièrement ce filtre, mais cela réintroduit le risque lié à la chaîne d'approvisionnement que pnpm 11 cherche à atténuer. La voie recommandée est d'approuver uniquement les paquets en qui vous avez confiance et qui ont véritablement besoin d'étapes postinstall, comme les compilateurs de binaires natifs.

La grande majorité fonctionne sans modification. Les problèmes apparaissent surtout avec les paquets qui supposent une structure node_modules plate ou qui reposent sur des dépendances fantômes. La plupart des bibliothèques populaires ont corrigé cela depuis longtemps. Si quelque chose casse, le paramètre public-hoist-pattern dans .npmrc peut reproduire le hoisting de style npm pour des paquets spécifiques en guise de solution de secours.

Pour les installations à froid, pnpm est généralement plus rapide grâce à sa résolution parallèle et à son store adressable par contenu. Pour les installations à chaud sur des projets partageant des dépendances, la différence est spectaculaire car pnpm réutilise les paquets déjà téléchargés via des hard links. En CI avec un cache rempli, l'écart se réduit mais pnpm conserve généralement un avantage.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.