Pourquoi pas npm (en 2026)

TL;DR : npm n'est pas mauvais, mais il a été conçu il y a quinze ans, à une époque où les projets faisaient cinq dépendances et où personne ne se préoccupait de la duplication sur disque. Aujourd'hui, deux concurrents (pnpm et bun) font le même travail plus vite, avec moins d'espace disque, et avec un comportement plus sûr. Tu n'as quasiment aucune raison de choisir npm pour un projet neuf en 2026.

Le problème historique de npm

Quand tu fais npm install dans un projet :

1. npm télécharge chaque dépendance une fois par projet, dans node_modules/.
2. Chaque sous-dépendance est elle aussi téléchargée et copiée, parfois plusieurs fois si elle est référencée par différents paquets en versions légèrement différentes.
3. Sur ton disque, un projet de taille moyenne pèse 300 Mo à 1 Go dans node_modules/. Si tu as dix projets, c'est dix fois ce volume.

Conséquence concrète : un dossier node_modules/ qui prend cinq minutes à installer, plusieurs gigaoctets sur ton SSD, et qui est généralement plus lourd que tout le reste du projet réuni.

Le deuxième problème : la résolution permissive

Par défaut, npm "aplatit" les dépendances. Un paquet A qui dépend de B peut, par effet de bord, accéder à n'importe quel paquet C qu'un autre paquet a installé, même si ton projet ne dépend pas explicitement de C. Ça s'appelle le phantom dependency problem.

Conséquence : ton code fonctionne en local, puis un jour une mise à jour de paquet supprime la dépendance fantôme, et ton build casse en production sans que tu aies touché à ton code. Diagnostic galère, douloureux à reproduire.

Le troisième problème : la vitesse

npm exécute beaucoup de tâches en série. Sur un projet de 100 dépendances, l'installation initiale prend facilement 30 à 60 secondes, parfois bien plus avec une connexion lente. Sur une CI qui réinstalle tout à chaque build, c'est du temps réel et du carbone gâché.

Ce que font pnpm et bun

• pnpm garde une copie unique de chaque paquet dans un store global (~/.local/share/pnpm/store ou équivalent), puis crée des hardlinks dans node_modules/. Sur disque, un seul fichier physique sert dix projets.
• bun est encore plus radical : binaire écrit en Zig, parallélisation agressive, installation 5 à 20 fois plus rapide que npm sur les benchmarks publics.
• Les deux appliquent par défaut une résolution stricte : un paquet ne peut accéder qu'à ses dépendances déclarées. Les bugs de dépendance fantôme deviennent impossibles.

Quand garder npm

• Projet existant déjà sur npm, avec une équipe formée et un package-lock.json qui marche. Pas urgent de migrer.
• Environnement très contraint : certains hébergeurs très anciens ne supportent que npm. De plus en plus rare en 2026.
• Compatibilité avec un outil tiers qui fait des hypothèses sur la structure de node_modules/. Là encore, rare.

En dehors de ces cas, pas de raison de choisir npm pour un projet neuf. La leçon suivante détaille les différences entre pnpm et bun pour faire un choix éclairé entre les deux.