npm Cache en node_modules nemen te veel ruimte in op je Mac? Wat je veilig kunt doen

Als npm cache en oude node_modules-mappen ruimte innemen op je Mac, scheid dan eerst de gedeelde npm cache van projectlokale afhankelijkheden. Bekijk de cache voordat je hem wist, en verwijder verouderde node_modules-mappen alleen als je klaar bent om opnieuw te installeren of het project niet meer intact nodig hebt.

Dat onderscheid is belangrijk omdat npm cache en node_modules verschillende problemen oplossen. Ze hebben ook verschillende opruimgevolgen.

De ene is een herbruikbare package-cache. De andere is de afhankelijkheidsstructuur waartegen je project daadwerkelijk draait. Ze als eenzelfde weg te gooien blob behandelen is hoe ontwikkelaars snel ruimte terugwinnen en dan tijd verliezen aan het herbouwen van de verkeerde omgeving.

Snel antwoord

Waarom npm cache en node_modules zo snel groeien op een Mac

JavaScript-ontwikkelaarsmachines groeien zelden door één project alleen. Het echte patroon is accumulatie.

Je installeert packages over meerdere apps, branches, prototypes en clientrepo’s. npm bewaart een herbruikbare cache zodat installs niet alles telkens opnieuw hoeven op te halen. Elk project houdt ook zijn eigen lokale afhankelijkheidsstructuur bij in node_modules.

Dat betekent dat schijfgroei uit twee richtingen tegelijk kan komen:

• een gedeelde npm cache die blijft groeien naarmate je nieuwe packages en versies installeert;
• meerdere projectmappen, elk met een eigen node_modules-structuur;
• gedupliceerde of bijna-gedupliceerde afhankelijkheden over oude repo’s;
• native modules en toolchain-packages die herbouwkosten toevoegen, zelfs als ze technisch weg te gooien zijn;
• verouderde projecten die nooit zijn gearchiveerd, verwijderd of schoon opnieuw geinstalleerd.

Het resultaat is herkenbaar: één repo is vervelend, tien repo’s zijn kostbaar, en een jaar normaal werk verandert in een sluimerend opslagprobleem.

npm Cache vs node_modules: Wat is het verschil?

Dit is het onderscheid dat er het meest toe doet.

Volgens de officiële npm-documentatie staan cachebestanden standaard in ~/.npm op Posix-systemen, terwijl lokale installs terechtkomen in ./node_modules onder de huidige package-root. npm laadt packages eerst in de cache en pakt ze vervolgens uit in node_modules voor het project dat ze nodig heeft.

Daarom is “npm neemt ruimte in” meestal te vaag om actie op te ondernemen. Je moet weten of de druk komt van de gedeelde cache, oude projectinstalls, of allebei.

Wat de eigen npm-documentatie impliceert

De npm cache is ontworpen als een cache, niet als de werkafhankelijkheidsstructuur van je project. npm documenteert het expliciet als een cache die later opnieuw kan worden opgebouwd.

node_modules is anders. Die map is waar de packages, uitvoerbare bestanden en de lokale afhankelijkheidsgraaf van je project daadwerkelijk leven. Als je die verwijdert, wis je niet alleen een cache. Je verwijdert de geinstalleerde afhankelijkheden die het project momenteel gebruikt.

Is het veilig om npm cache te verwijderen op een Mac?

Meestal wel, maar de reden is belangrijk.

De officiële npm-documentatie stelt dat de cache integriteits-geverifieerd is en dat het wissen ervan doorgaans alleen nodig is als het doel het terugwinnen van schijfruimte is. Dat is een belangrijk onderscheid in formulering. De npm cache hoort niet als kostbare state te worden behandeld, maar het is ook niet iets dat je routinematig moet wissen alleen omdat het bestaat.

Het veilige mentale model is:

• als je Mac weinig ruimte heeft, kan cache-opruiming een redelijke afweging zijn;
• als je installs normaal werken, is het wissen van de cache vaak overbodig;
• als je hem wist, verwacht dan dat latere installs packages opnieuw downloaden;
• als je alleen eerst de cachestaat wilt controleren, gebruik dan npm cache verify.

Betere eerste stap: verifieer voordat je wist

npm documenteert npm cache verify als de offline verificatiestap voor bestaande cache-inhoud. Dat maakt het de betere eerste opdracht als je een risico-armere check wilt voordat je ruimte terugwint.

npm cache verify

Als je specifiek schijfruimte vrij wilt maken, is de gedocumenteerde opruimopdracht van npm:

npm cache clean --force

De --force-vlag is bewist vereist. npm behandelt het wissen van de cache als een bewuste schijfruimte-beslissing, niet als een dagelijkse onderhoudsgewoonte.

Is het veilig om node_modules te verwijderen op een Mac?

Soms wel, maar hier is context veel belangrijker.

Het verwijderen van node_modules haalt de lokale afhankelijkheidsstructuur voor dat project weg. Als het project actief is, is het directe gevolg meestal voor de hand liggend: scripts kunnen packages niet meer vinden, lokale binaries verdwijnen uit node_modules/.bin, en de volgende install of build kan langer duren dan je wilt.

Dat betekent niet dat je het nooit moet verwijderen. Het betekent dat je het bewust moet verwijderen.

Goede kandidaten voor het verwijderen van node_modules:

• een oud project dat je niet meer actief draait;
• een verouderde demo of prototype die je later kunt herbouwen;
• een repo die je toch schoon opnieuw gaat installeren;
• een project met een betrouwbare lockfile waar opnieuw installeren verwacht en acceptabel is.

Moeilijkere situaties:

• een actieve werk-repo vlak voor een deadline, demo of release-build;
• een project met native modules die tijd kosten om te herbouwen;
• een werkruimte die je in maanden niet hebt aangeraakt en die je misschien niet snel meer kunt herstellen;
• een repo zonder een schone afhankelijkheidsgeschiedenis of zonder de lockfile die je verwacht.

Waarom oude node_modules-mappen zoveel pijn doen

Eén project is nog behapbaar. De echte verspilling komt door er veel van te hebben.

Elke oude repo kan een volledige afhankelijkheidsstructuur, package-manager-metadata, optionele native packages, framework-toolchains en versiespecifieke artefacten bevatten. Daarom denken ontwikkelaars vaak dat npm het probleem is, terwijl de grotere boosdoener eigenlijk een stapel vergeten node_modules-mappen over gepensioneerde repo’s is.

Hoe wis je npm cache handmatig

Als je de handmatige route kiest, houd het dan smal en expliciet.

1. Controleer de actieve cachemap

Als je op enig moment je npm-configuratie hebt gewijzigd, staat je cache mogelijk niet op de standaardlocatie. Vraag het npm eerst:

npm config get cache

2. Verifieer de cache voordat je hem verwijdert

Gebruik eerst de gedocumenteerde verificatiestap:

npm cache verify

3. Wis de cache alleen als je de ruimte echt terug wilt

Als het terugwinnen van schijfruimte de latere her-downloads waard is:

npm cache clean --force

4. Controleer de grootte indien nodig

Zodra je het cachepad kent, kun je de grootte direct inspecteren:

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

Dit is de veiligere volgorde omdat het locatie, verificatie en opruiming in afzonderlijke beslissingen verdeelt.

Hoe vind je oude node_modules-mappen voordat je iets verwijdert

Dit is meestal de waardevollere opruimronde.

Begin met de projecten die je niet meer actief bouwt. Dat is belangrijker dan de ene grootste map in Finder najagen zonder context.

Gebruik een beoordelingsvolgorde als deze:

1. Doorzoek je hoofdprojectenmap op node_modules-mappen.
2. Controleer welke repo’s verouderd, gearchiveerd of makkelijk opnieuw te installeren zijn.
3. Bevestig of het project deze week nog lokaal hoeft te draaien.
4. Verwijder alleen de node_modules-mappen waarvan je de herbouwkosten begrijpt.

Als je een Terminal-ondersteunde beoordeling wilt, gebruik dan opdrachten die je laten zien waar die mappen zich bevinden voordat je iets verwijdert:

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

Dat is nog steeds handmatig, maar beter dan emotioneel reageren op één enorme werkmap.

Wat je moet bekijken voordat je de node_modules van een project verwijdert

• Is de repo nog actief?
• Heb je de lockfile die je verwacht?
• Zijn er native modules of codegen-stappen die opnieuw installeren trager maken?
• Is het project onderdeel van een monorepo of werkruimte-setup die je niet zomaar wilt verstoren?
• Zou het archiveren of verwijderen van het hele gepensioneerde project een betere opruimming zijn dan alleen het verwijderen van node_modules?

Vaak is de sterkste opruimactie niet “afhankelijkheden overal wissen.” Het is “het oude project verwijderen dat je niet meer nodig hebt.”

En yarn-, pnpm- en bun-caches?

Houd dit deel los van npm.

Als het project een andere package-manager gebruikt, gebruik dan het eigen opruimmodel van die package-manager in plaats van aan te nemen dat npm-opdrachten zomaar van toepassing zijn.

Yarn

Moderne Yarn documenteert yarn cache clean als de opdracht die gedeelde cachebestanden verwijdert. Het biedt ook --mirror en --all voor bredere opruimscopes.

yarn cache clean

pnpm

pnpm gebruikt een store-model in plaats van npm’s exacte cachepatroon. De officiële pnpm-documentatie omschrijft pnpm store prune als het verwijderen van niet-gerefereerde packages uit de store en merkt op dat toekomstige installs verwijderde packages opnieuw kunnen downloaden wanneer nodig.

pnpm store prune

Bun

Bun documenteert een globale package-cache op ~/.bun/install/cache standaard. De documentatie merkt ook op dat packages na downloaden nog steeds naar node_modules worden gekopieerd, dus Bun kan dezelfde “cache plus project-installatie”-verwarring creëren als je alleen naar mapgrootte kijkt.

Het belangrijke deel is niet om elke opdracht uit je hoofd te leren. Het is om opslagmodellen niet te vermengen. npm cache, Yarn cache, pnpm store en Bun cache zijn gerelateerde problemen, geen identieke.

Waarom ontwikkelaarsopruiming veiliger is als je per ecosysteem beoordeelt

node_modules is zelden het enige opslagprobleem van een ontwikkelaar op een Mac. Het staat meestal naast Xcode-gegevens, simulator-opslag, Docker-images, build-cache, logs en andere toolchain-specifieke paden.

Een gewone bestandsbrowser laat zien dat een map groot is. Die zegt je niet of het:

• een herbouwbare npm cache is;
• de afhankelijkheidsstructuur van een actieve werkruimte;
• een pnpm store;
• een Docker-cache;
• of een ander ecosysteem dat toevallig in de buurt van je projecten staat.

Daarom werkt ontwikkelaarsopruiming beter als de workflow ecosysteem-bewust blijft.

Als je werkelijke situatie “npm plus Docker plus oude Xcode-gegevens plus te veel verouderde repo’s” is, is dat bredere review-first-model bruikbaarder dan de ene map na de andere najagen.

Conclusie

Als npm cache en node_modules ruimte innemen op je Mac, behandel ze dan niet als hetzelfde opruimdoel.

Gebruik npm cache verify en, als het terugwinnen van ruimte het daadwerkelijke doel is, npm cache clean --force voor de gedeelde cache. Bekijk oude node_modules-mappen project voor project, en verwijder ze alleen als je de kosten van opnieuw installeren begrijpt.

Dat is het veiligere pad: scheid cache van werkruimte-state, beoordeel verouderde projecten voordat je actieve aanpakt, en houd ontwikkelaarsopruiming gekoppeld aan ecosysteemcontext in plaats van blinde mapverwijdering.