Le cache npm et les node_modules mangent de l'espace sur ton Mac ? Que faire sans tout casser

Si le cache npm et les vieux dossiers node_modules mangent de l’espace sur ton Mac, commence par séparer le cache npm partagé des dépendances locales à chaque projet. Examine le cache avant de le vider, puis supprime les node_modules obsolètes uniquement quand tu es prêt à réinstaller ou quand tu n’as plus besoin de ce projet intact.

Cette distinction compte parce que npm cache et node_modules résolvent des problèmes différents. Ils impliquent aussi des conséquences de nettoyage très différentes.

L’un est un cache de paquets réutilisable. L’autre est l’arbre de dépendances contre lequel ton projet s’exécute réellement. Les traiter comme un seul bloc jetable, c’est le moyen le plus sûr de récupérer de l’espace rapidement… puis de perdre du temps à reconstruire le mauvais environnement.

Réponse rapide

Pourquoi le cache npm et node_modules grandissent si vite sur Mac

Les machines des développeurs JavaScript grossissent rarement à cause d’un seul projet. Le vrai schéma, c’est l’accumulation.

Tu installes des paquets across plusieurs applis, branches, prototypes et dépôts clients. npm garde un cache réutilisable pour que les installations n’aient pas à tout re-télécharger depuis zéro à chaque fois. Chaque projet conserve aussi son propre arbre de dépendances local dans node_modules.

Donc la croissance du disque peut venir de deux directions à la fois :

• un cache npm partagé qui continue de grossir à mesure que tu installes de nouveaux paquets et versions ;
• plusieurs dossiers de projets, chacun avec son propre arbre node_modules ;
• des dépendances dupliquées ou quasi-dupliquées entre de vieux dépôts ;
• des modules natifs et des paquets de toolchain qui ajoutent un coût de reconstruction même s’ils sont techniquement jetables ;
• des projets obsolètes qui n’ont jamais été archivés, supprimés ou réinstallés proprement.

Le résultat est familier : un dépôt est gênant, dix dépôts coûtent cher, et un an de travail normal se transforme en un problème de stockage silencieux.

Cache npm vs node_modules : quelle est la différence ?

C’est la distinction qui compte le plus.

Selon la documentation officielle de npm, les fichiers de cache se trouvent dans ~/.npm sur les systèmes Posix par défaut, tandis que les installations locales vont dans ./node_modules sous la racine du paquet courant. npm charge d’abord les paquets dans le cache, puis les décompresse dans node_modules pour le projet qui en a besoin.

C’est pourquoi dire « npm prend de la place » est généralement trop vague pour être utile. Tu dois savoir si la pression vient du cache partagé, des installations de vieux projets, ou des deux.

Ce que la documentation de npm implique

Le cache npm est conçu comme un cache, pas comme l’arbre de dépendances de travail de ton projet. npm le documente explicitement comme un cache qui peut être repeuplé ultérieurement.

node_modules est différent. Ce dossier est l’endroit où vivent réellement les paquets, exécutables et graphe de dépendances local de ton projet. Si tu le supprimes, tu ne nettoies pas juste un cache. Tu retires les dépendances installées que le projet utilise actuellement.

Est-il sûr de supprimer le cache npm sur Mac ?

En général oui, mais la raison compte.

La documentation officielle de npm indique que le cache est vérifié en intégrité et que le vider ne devrait généralement être nécessaire que lorsque l’objectif est de récupérer de l’espace disque. C’est une nuance importante. Le cache npm n’est pas censé être traité comme un état précieux, mais ce n’est pas non plus quelque chose que tu dois vider systématiquement juste parce qu’il existe.

Le bon modèle mental, c’est :

• si ton Mac est à court d’espace, le nettoyage du cache peut être un compromis raisonnable ;
• si tes installations fonctionnent normalement, vider le cache est souvent inutile ;
• si tu le vides, attends-toi à ce que les prochaines installations retéléchargent les paquets ;
• si tu veux d’abord vérifier l’état du cache, utilise npm cache verify.

Meilleur premier mouvement : vérifier avant de nettoyer

npm documente npm cache verify comme l’étape de vérification hors ligne du contenu existant du cache. Ça en fait la meilleure première commande quand tu veux un contrôle à moindre risque avant de récupérer de l’espace.

npm cache verify

Si ton objectif est spécifiquement de libérer de l’espace disque, la commande documentée par npm est :

npm cache clean --force

Le flag --force est requis par conception. npm traite le vidage du cache comme une décision délibérée d’espace disque, pas comme une habitude d’entretien quotidienne.

Est-il sûr de supprimer node_modules sur Mac ?

Parfois, mais c’est là que le contexte compte beaucoup plus.

Supprimer node_modules retire l’arbre de dépendances local pour ce projet. Si le projet est actif, la conséquence immédiate est généralement évidente : les scripts ne trouvent plus les paquets, les binaires locaux disparaissent de node_modules/.bin, et la prochaine installation ou build peut prendre plus de temps que souhaité.

Ça ne veut pas dire que tu ne dois jamais le supprimer. Ça veut dire que tu dois le faire délibérément.

Bons candidats pour la suppression de node_modules :

• un vieux projet que tu n’exécutes plus activement ;
• une démo ou un prototype obsolète que tu peux reconstruire plus tard ;
• un dépôt que tu vas réinstaller proprement de toute façon ;
• un projet avec un lockfile fiable où la réinstallation est prévue et acceptable.

Situations plus délicates :

• un dépôt de travail actif juste avant une deadline, une démo ou un build de release ;
• un projet avec des modules natifs qui prennent du temps à reconstruire ;
• un workspace que tu n’as pas touché depuis des mois et dont tu ne te souviens peut-être plus comment le restaurer rapidement ;
• un dépôt sans une histoire de dépendances propre ou sans le lockfile attendu.

Pourquoi les vieux dossiers node_modules font si mal

Un seul projet peut être gérable. Le vrai gâchis vient du fait d’en avoir beaucoup.

Chaque vieux dépôt peut conserver un arbre de dépendances complet, des métadonnées de gestionnaire de paquets, des paquets natifs optionnels, des toolchains de framework et des artefacts spécifiques à une version. C’est pourquoi les développeurs pensent souvent que npm est le problème alors que le plus gros responsable est en fait un tas de dossiers node_modules oubliés dans des dépôts abandonnés.

Comment vider le cache npm manuellement

Si tu préfères la méthode manuelle, reste ciblé et explicite.

1. Vérifie le répertoire de cache actif

Si tu as modifié la config npm à un moment donné, ton cache peut ne pas être dans l’emplacement par défaut. Demande d’abord à npm :

npm config get cache

2. Vérifie le cache avant de le supprimer

Utilise d’abord l’étape de vérification documentée :

npm cache verify

3. Nettoie le cache uniquement si tu veux vraiment récupérer l’espace

Si récupérer de l’espace disque justifie les futurs re-téléchargements :

npm cache clean --force

4. Revérifie la taille si nécessaire

Une fois que tu connais le chemin du cache, tu peux inspecter sa taille directement :

du -sh "$(npm config get cache)"

C’est la séquence la plus sûre parce qu’elle sépare la localisation, la vérification et le nettoyage en décisions distinctes.

Comment trouver les vieux dossiers node_modules avant de supprimer quoi que ce soit

C’est généralement la passe de nettoyage la plus rentable.

Commence par les projets que tu ne buildes plus activement. Ça compte plus que de chasser le plus gros dossier dans Finder sans aucun contexte.

Utilise un ordre de révision comme celui-ci :

1. Cherche dans ton répertoire de projets principal les dossiers node_modules.
2. Vérifie quels dépôts sont obsolètes, archivés ou faciles à réinstaller.
3. Confirme si le projet a encore besoin de tourner localement cette semaine.
4. Supprime uniquement les dossiers node_modules dont tu comprends le coût de reconstruction.

Si tu veux une révision assistée par Terminal, utilise des commandes qui te montrent où se trouvent ces dossiers avant de supprimer quoi que ce soit :

find ~/Projects -type d -name node_modules -prune -print
find ~/Projects -type d -name node_modules -prune -exec du -sh {} +

C’est encore manuel, mais c’est mieux que de réagir émotionnellement à un énorme dossier de travail.

Ce qu’il faut vérifier avant de supprimer les node_modules d’un projet

• Le dépôt est-il encore actif ?
• As-tu le lockfile attendu ?
• Y a-t-il des modules natifs ou des étapes de codegen qui ralentissent la réinstallation ?
• Le projet fait-il partie d’un monorepo ou d’un workspace que tu ne veux pas perturber à la légère ?
• Archiver ou supprimer entièrement le projet retiré serait-il un meilleur nettoyage que de juste retirer node_modules ?

Souvent, l’action de nettoyage la plus forte n’est pas « effacer les dépendances partout ». C’est « supprimer le vieux projet dont tu n’as plus besoin ».

Et les caches yarn, pnpm et bun ?

Garde cette partie séparée de npm.

Si le projet utilise un autre gestionnaire de paquets, utilise le modèle de nettoyage propre à ce gestionnaire au lieu de supposer que les commandes npm s’appliquent directement.

Yarn

Yarn moderne documente yarn cache clean comme la commande qui supprime les fichiers de cache partagé. Il expose aussi --mirror et --all pour des périmètres de nettoyage plus larges.

yarn cache clean

pnpm

pnpm utilise un modèle de store plutôt que le pattern exact de cache de npm. La documentation officielle de pnpm décrit pnpm store prune comme retirant les paquets non référencés du store et note que les prochaines installations pourront retélécharger les paquets supprimés si besoin.

pnpm store prune

Bun

Bun documente un cache de paquets global à ~/.bun/install/cache par défaut. Sa documentation note aussi que les paquets sont toujours copiés dans node_modules après le téléchargement, donc Bun peut créer la même confusion « cache plus installation de projet » si tu regardes seulement la taille des dossiers.

L’important n’est pas de mémoriser chaque commande. C’est d’éviter de mélanger les modèles de stockage. Le cache npm, le cache Yarn, le store pnpm et le cache Bun sont des problèmes liés, pas identiques.

Pourquoi le nettoyage développeur est plus sûr quand on examine par écosystème

node_modules est rarement le seul problème de stockage développeur sur un Mac. Il se trouve généralement à côté de données Xcode, de stockage de simulateurs, d’images Docker, de cache de build, de logs et d’autres chemins spécifiques aux toolchains.

Un navigateur de fichiers classique montre qu’un dossier est volumineux. Il ne te dit pas si c’est :

• un cache npm reconstruisible ;
• un arbre de dépendances de workspace actif ;
• un store pnpm ;
• un cache Docker ;
• ou un autre écosystème qui se trouve juste à côté de tes projets.

C’est pourquoi le nettoyage développeur fonctionne mieux quand le workflow reste conscient de l’écosystème.

Si ta vraie situation est « npm plus Docker plus les vieilles données Xcode plus trop de dépôts obsolètes », ce modèle de révision d’abord plus large est bien plus utile que de chasser un dossier à la fois.

En résumé

Si le cache npm et node_modules prennent de la place sur ton Mac, ne les traite pas comme la même cible de nettoyage.

Utilise npm cache verify et, quand récupérer de l’espace est le véritable objectif, npm cache clean --force pour le cache partagé. Examine les vieux dossiers node_modules projet par projet, et supprime-les uniquement quand tu comprends le coût de réinstallation.

C’est le chemin le plus sûr : sépare le cache de l’état du workspace, examine les projets obsolètes avant les actifs, et garde le nettoyage développeur lié au contexte de l’écosystème plutôt qu’à une suppression aveugle de dossiers.