node_modules dévore votre disque ? Les trouver et les vider

Pourquoi node_modules prend autant de place

Avec npm et Yarn, chaque projet reçoit sa propre copie complète de chaque dépendance, et de tout ce dont ces dépendances ont besoin. Une petite app web peut entraîner un très grand arbre de paquets. Dix anciens projets, ce sont dix copies distinctes.

Ces dossiers sont aussi faits d'un nombre énorme de petits fichiers, ce qui explique qu'ils soient lents à copier, lents à sauvegarder et lents à indexer. Rien de ce qu'ils contiennent n'est à vous. La liste de ce qu'il faut installer se trouve dans package.json et dans le fichier de verrouillage (lockfile), et ce sont eux que vous gardez.

Lister tous les dossiers node_modules par taille

La commande ci-dessous cherche les répertoires node_modules dans un dossier, mesure chacun d'eux et trie la liste avec les plus volumineux en dernier. Elle se contente de lire. Remplacez ~/Projects par le dossier où vous rangez votre code.

Pointez-la sur votre dossier de code, pas sur tout votre dossier de départ. Les apps et les éditeurs ont leurs propres dossiers node_modules dans ~/Library et à l'intérieur des paquets d'applications, et ceux-là font partie de l'app : ce ne sont pas des restes. Les supprimer casse l'app.

find ~/Projects -type d -name node_modules -prune -exec du -sh {} + 2>/dev/null | sort -h

Décidez lesquels supprimer

Supprimer node_modules ne vous coûte que le temps de la prochaine installation, et la question est donc de savoir quels projets vous allez bientôt rouvrir.

• Les projets auxquels vous n'avez pas touché depuis des mois : supprimez. C'est là que se trouve l'essentiel de l'espace.
• Les dépôts clonés que vous avez seulement lus ou essayés une fois : supprimez.
• Les projets sur lesquels vous travaillez cette semaine : laissez-les. Vous ne feriez que réinstaller aussitôt.
• Les projets sans fichier de verrouillage : réfléchissez d'abord. Une nouvelle installation peut aboutir, pour certains paquets, à des versions plus récentes que celles que vous aviez, ce qui peut modifier le comportement.
• Les projets qui dépendent d'un registre privé ou de paquets qui ne sont peut-être plus publiés : assurez-vous de pouvoir encore installer avant de supprimer.

Supprimez-les sans risque

Arrêtez d'abord tout serveur de développement ou tout build en cours dans le projet. Ensuite, dans le Finder, ouvrez le dossier du projet et placez node_modules dans la corbeille. C'est la méthode qui pardonne : si la réinstallation échoue, vous pouvez remettre le dossier en place avant de vider la corbeille.

Quand vous revenez au projet, exécutez la commande d'installation du gestionnaire de paquets qu'il utilise, indiquée ci-dessous pour npm. Si le projet a un fichier package-lock.json, npm ci installe exactement les versions qui y sont enregistrées.

Les autres résultats de build des mêmes projets peuvent suivre le même chemin : des dossiers comme .next, dist, build et .turbo sont recréés par le prochain build.

npm install

Videz les caches des gestionnaires de paquets

En dehors de vos projets, chaque gestionnaire de paquets garde un cache de tout ce qu'il a téléchargé, pour que les installations répétées soient rapides. Ces caches ne font que grossir. Les commandes ci-dessous sont les méthodes documentées pour les vider, et chacune ne supprime que le cache de téléchargement de l'outil concerné. Vos projets continuent de fonctionner, et la prochaine installation télécharge à nouveau.

• npm garde son cache dans ~/.npm. npm exige --force parce qu'il considère que le cache se répare de lui-même. Pour le vérifier sans le vider, exécutez npm cache verify.
• Yarn 1 garde un cache global, et yarn cache clean le vide. Sur les versions plus récentes de Yarn, exécutez la commande à l'intérieur d'un projet.
• pnpm garde un magasin partagé (store). pnpm store prune ne supprime que les paquets auxquels plus aucun projet de votre Mac ne fait référence.
• Bun garde un cache global, et bun pm cache rm le vide.

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

Occuper moins de place dès le départ

pnpm stocke chaque version d'un paquet une seule fois sur le disque et la relie à chaque projet qui l'utilise : dix projets ayant les mêmes dépendances n'occupent donc guère plus qu'un seul. Si node_modules est un problème récurrent, passer à pnpm pour les nouveaux projets est la solution durable.

Un effet secondaire est que les tailles paraissent fausses. Un outil qui additionne les tailles des fichiers compte un paquet lié une fois par projet, si bien qu'un dossier node_modules géré par pnpm peut sembler bien plus volumineux que l'espace qu'il occupe réellement.

Il est aussi utile de garder le code hors des dossiers synchronisés. Un dossier node_modules placé dans iCloud Drive ou Dropbox, c'est un nombre énorme de petits fichiers envoyés sans aucun bénéfice.

Comment Diskzy traite node_modules

L'onglet Clean up (nettoyage) de Diskzy trouve les dossiers de build des projets, dont node_modules, .build, Pods et les environnements virtuels, où qu'ils soient sur le disque. Un dossier reste décoché si son projet a changé au cours des 14 derniers jours : les projets sur lesquels vous travaillez ne sont donc pas touchés, sauf si vous les sélectionnez.

Les caches de npm, Yarn, pnpm et Bun sont listés et cochés. Tout ce qui est supprimé va dans la corbeille : un dossier peut donc être remis en place tant que vous ne l'avez pas vidée.