Des node_modules partout : comment les trouver, les nettoyer et les récupérer

Un dossier node_modules contient les dépendances installées pour un projet JavaScript ou TypeScript, et pèse en général quelques centaines de mégaoctets. Avec des dizaines d’anciens projets, ils atteignent facilement plusieurs dizaines de gigaoctets. On peut les supprimer sans risque tant qu’on garde package.json et le lockfile : votre gestionnaire de paquets réinstalle les mêmes versions quand vous revenez au projet.

Trouver chaque dossier node_modules et sa taille

Cette commande parcourt votre dossier de départ, ignore ~/Library et la corbeille, et affiche chaque dossier node_modules avec sa taille, les plus gros en dernier :

find ~ \( -path "$HOME/Library" -o -path "$HOME/.Trash" \) -prune -o -type d -name node_modules -prune -print0 2>/dev/null | xargs -0 du -sh 2>/dev/null | sort -h

Fonctionnement : le premier -prune ignore les deux dossiers exclus, -type d -name node_modules repère les dossiers, et le second -prune empêche find d’y descendre, si bien que les node_modules imbriqués sont comptés une seule fois, dans leur parent. du -sh mesure chacun et sort -h trie la liste. La commande se contente de lire. Sur un gros dossier de départ, elle peut prendre quelques minutes, et Terminal peut demander l’accès à Documents, Bureau ou Téléchargements.

Ignorez les résultats situés dans des dossiers d’outils comme ~/.nvm, ~/.vscode ou ~/.cursor. Ils appartiennent à des outils installés et à des extensions d’éditeur, pas à vos projets.

Si vos projets utilisent pnpm, les tailles affichées sont supérieures à ce que vous récupéreriez. La raison est expliquée plus bas.

Supprimer ceux dont vous n’avez pas besoin

Avant de supprimer, ouvrez le dossier du projet et vérifiez qu’il contient un lockfile : package-lock.json (npm), pnpm-lock.yaml (pnpm), yarn.lock (Yarn) ou bun.lock / bun.lockb (Bun). Gardez-le, ainsi que package.json.

La façon la plus sûre de supprimer est de glisser node_modules dans la corbeille depuis le Finder. Vous pouvez changer d’avis tant que la corbeille n’est pas vidée. Avec beaucoup de petits fichiers, le placement dans la corbeille prend un moment.

Depuis Terminal, dans le dossier d’un projet :

cd ~/Projects/old-app
rm -rf node_modules

rm -rf supprime définitivement, sans passer par la corbeille. Vérifiez d’abord le dossier où vous vous trouvez avec pwd, et ne l’exécutez jamais avec un caractère générique ou une variable vide.

npkill : une alternative interactive

npkill liste les dossiers node_modules avec leur taille et permet de les supprimer d’une simple touche :

npx npkill -d ~/Projects

-d définit le point de départ de la recherche ; sans lui, npkill part du dossier courant. Déplacez-vous avec les flèches et appuyez sur Espace ou Suppr pour supprimer le dossier sélectionné. npkill supprime immédiatement, sans passer par la corbeille. Il marque d’un ⚠️ les dossiers dont des apps ont besoin pour fonctionner : laissez-les tranquilles. --dry-run simule la suppression si vous voulez d’abord faire un essai.

Réinstaller en revenant à un projet

Utilisez la commande qui installe exactement ce que dit le lockfile :

npm ci exige un lockfile, supprime d’abord tout node_modules existant et ne modifie jamais package.json ni le lockfile. Un simple npm install fonctionne aussi, mais peut mettre à jour le lockfile.

Les autres dossiers qui se reconstruisent seuls

Les frameworks et outils de build gardent des caches et des fichiers produits à côté de node_modules. On peut les supprimer sans risque dans les projets qu’on n’exécute pas ; le prochain build ou serveur de développement les recrée.

dist et build contiennent généralement eux aussi des fichiers produits par le build, mais ces noms sont génériques. Certains projets y versionnent des fichiers ou s’en servent pour autre chose : regardez à l’intérieur avant de supprimer.

Pour lister les caches de frameworks d’un dossier de projets :

find ~/Projects -type d \( -name .next -o -name .nuxt -o -name .svelte-kit -o -name .turbo -o -name .parcel-cache \) -prune -print0 | xargs -0 du -sh | sort -h

Vider les caches globaux de paquets

Chaque gestionnaire de paquets garde aussi un cache de téléchargement partagé par tous les projets. Le vider est définitif mais sans conséquence : les paquets sont retéléchargés au besoin.

npm cache clean --force
pnpm store prune
yarn cache clean
bun pm cache rm

• npm garde son cache dans ~/.npm/_cacache. La documentation du cache npm explique pourquoi clean exige --force et précise que npm cache verify fait le ménage sans tout vider. Les paquets récupérés par npx se trouvent dans ~/.npm/_npx.
• pnpm garde son magasin dans ~/Library/pnpm/store sur macOS (pnpm store path affiche le vôtre). pnpm store prune ne supprime que les paquets qu’aucun projet ne référence, et la documentation de pnpm conseille de l’exécuter de temps en temps plutôt qu’en permanence.
• Yarn Classic met en cache dans ~/Library/Caches/Yarn. Pour Yarn Berry, yarn cache clean --mirror vide le cache global dans ~/.yarn/berry/cache.
• Bun met en cache dans ~/.bun/install/cache ; bun pm cache rm le vide.

Les anciennes versions de Node.js installées avec nvm s’accumulent aussi dans ~/.nvm/versions/node ; nvm uninstall <version> supprime celle dont vous n’avez plus besoin.

Pourquoi pnpm libère moins que ce qu’annonce du

npm et Yarn Classic copient chaque paquet dans le node_modules de chaque projet. pnpm stocke chaque paquet une seule fois, dans un magasin adressé par contenu, et lie ses fichiers dans chaque projet qui l’utilise. Sur macOS, la méthode packageImportMethod par défaut de pnpm essaie d’abord les clones APFS, puis les liens physiques.

Dans les deux cas, les octets sont partagés. du compte pourtant la taille complète dans chaque projet : supprimer le node_modules d’un projet pnpm libère donc en général bien moins que la taille annoncée. L’espace revient quand pnpm store prune supprime les paquets qu’aucun projet restant n’utilise. Pour que cela fonctionne, le magasin doit être sur le même disque que le projet ; les projets situés sur un disque externe y ont leur propre magasin.

Comment MoreRoom vous aide

La version gratuite de MoreRoom trouve les dossiers node_modules des projets qui ont un lockfile et n’ont pas été modifiés depuis 30 jours, ainsi que les caches de frameworks comme .next et .turbo, et les marque « Sans risque ». Elle ignore ~/Library et les dossiers d’outils comme ~/.nvm et ~/.vscode. Vous placez les éléments dans la corbeille un par un, avec Annuler. Pour le cache npm et le magasin pnpm, MoreRoom exécute npm cache clean --force et pnpm store prune ; ces commandes sont définitives et signalées comme telles.

MoreRoom Pro ajoute l’hibernation de projets : les projets inactifs se délestent des dossiers reconstructibles comme node_modules et les fichiers produits par le build, puis se réveillent en un clic quand vous y revenez. Pro inclut aussi le Collecteur et le mode objectif.