Så rensar du npm-cachen säkert på Mac
AskClean-teamet · Uppdaterad 2026-08-05
Hitta den aktiva cachen med npm config get cache, mät exakt den sökvägen och kör npm cache verify innan du raderar något. Använd npm cache clean --force bara när du verkligen behöver utrymmet och accepterar framtida hämtningar. node_modules, package.json och låsfilen hör inte till cachen och ska lämnas orörda.
Skilj npm-cachen från beroenden och projektfiler
npm-cachen lagrar återanvändbara hämtningar för flera projekt och finns normalt under ~/.npm på macOS, men den kan ha konfigurerats om. node_modules är i stället ett projekts installerade beroendeträd. package.json och package-lock.json är projektdata, inte cache. npm-shrinkwrap.json är inte heller cache. npm v12 läser inte längre filen; om den är projektets enda låsfil ska du byta namn på den till package-lock.json, men aldrig skriva över en befintlig package-lock.json.
Mät den aktiva cachen och verifiera först
Utgå inte från att en befintlig ~/.npm är den aktiva cachen. npm config get cache visar sökvägen för den aktuella konfigurationen; mät just den sökvägen med du och notera ledigt utrymme. npm cache verify kontrollerar index och innehåll, verifierar integriteten och städar bort data som inte behövs utan att kasta alla giltiga hämtningar. För normalt underhåll räcker det ofta.
- Kör npm --version och npm config get cache och bekräfta att den visade sökvägen är en cacheplats, inte en projektmapp.
- Mät exakt den sökvägen med du -sh och notera ledigt utrymme i macOS; lämna package.json och låsfiler oförändrade.
- Stoppa aktiva npm install-, npm ci-, npm exec- och publiceringsprocesser, kör npm cache verify och spara sammanfattningen och eventuella fel.
- Kör npm cache clean --force bara om verifieringen inte räcker, utrymmesvinsten är relevant och alla nödvändiga artefakter kan nås igen.
- Kör npm cache verify igen, mät samma sökväg och testa ett representativt projekt med oförändrad låsfil, bygge och tester.
Skicka aldrig en okontrollerad sökväg till rm -rf. Kombinera inte heller cacherensning med att radera eller skapa om en låsfil: då ändrar du två orsaker samtidigt och förlorar jämförelseunderlaget.
Använd npm cache clean --force medvetet
Kör npm cache clean --force endast när den uppmätta cachen är stor nog att spela roll, utrymmet behövs nu och paketen kan hämtas igen. Kommandot rensar den konfigurerade cachen, inte node_modules eller låsfiler. Efteråt kan installationer och npm ci bli långsammare eller misslyckas offline; privata paketregister, Git-värdar, proxyservrar och paket som försvunnit ökar återställningskostnaden. Gör inte force till en bestående npm-inställning.
Verifiera utan att ändra beroendeträdet
Hämta cachesökvägen igen efter rensningen, mät samma plats och jämför faktiskt ledigt utrymme i macOS. Testa ett representativt projekt med oförändrade package.json och låsfil samt dess bygge och tester. Om felet återkommer ska du inte rensa igen: ERESOLVE, saknad autentisering, 404, proxy- eller certifikatfel, Node.js-motorer, byggen av native-moduler och livscykelskript kräver egen felsökning. AskClean känner igen standardplatsen ~/.npm; kontrollera anpassade sökvägar med npm.
Raderingsgränser och återställningskostnad
Hitta och mät den aktiva npm-cachen, verifiera den först och rensa bara med goda skäl utan att röra node_modules eller projektfiler.
| Objekt eller åtgärd | Kontrollera med eller på | Följd |
|---|---|---|
| Skilj npm-cachen från beroenden och projektfiler | npm config get cache | npm-cachen lagrar återanvändbara hämtningar för flera projekt och finns normalt under ~/.npm på macOS, men den kan ha konfigurerats om. node_modules är i stället ett projekts installerade beroendeträd. package.json och package-lock.json är projektdata, inte cache. npm-shrinkwrap.json är inte heller cache. npm v12 läser inte längre filen; om den är projektets enda låsfil ska du byta namn på den till package-lock.json, men aldrig skriva över en befintlig package-lock.json. |
| Mät den aktiva cachen och verifiera först | npm cache verify | Utgå inte från att en befintlig ~/.npm är den aktiva cachen. npm config get cache visar sökvägen för den aktuella konfigurationen; mät just den sökvägen med du och notera ledigt utrymme. npm cache verify kontrollerar index och innehåll, verifierar integriteten och städar bort data som inte behövs utan att kasta alla giltiga hämtningar. För normalt underhåll räcker det ofta. |
| Använd npm cache clean --force medvetet | npm cache clean --force | Kör npm cache clean --force endast när den uppmätta cachen är stor nog att spela roll, utrymmet behövs nu och paketen kan hämtas igen. Kommandot rensar den konfigurerade cachen, inte node_modules eller låsfiler. Efteråt kan installationer och npm ci bli långsammare eller misslyckas offline; privata paketregister, Git-värdar, proxyservrar och paket som försvunnit ökar återställningskostnaden. Gör inte force till en bestående npm-inställning. |
| Verifiera utan att ändra beroendeträdet | installation + kontroll av offlinearbete och privata paketregister | Hämta cachesökvägen igen efter rensningen, mät samma plats och jämför faktiskt ledigt utrymme i macOS. Testa ett representativt projekt med oförändrade package.json och låsfil samt dess bygge och tester. Om felet återkommer ska du inte rensa igen: ERESOLVE, saknad autentisering, 404, proxy- eller certifikatfel, Node.js-motorer, byggen av native-moduler och livscykelskript kräver egen felsökning. AskClean känner igen standardplatsen ~/.npm; kontrollera anpassade sökvägar med npm. |
Vanliga frågor
Är npm cache clean --force säkert på en Mac?
Det lämnar källkod och projektfiler i fred om npm pekar på rätt cache, men återanvändbara hämtningar försvinner. Mät och verifiera först och räkna med att senare installationer behöver nätverksåtkomst.
Ska jag köra npm cache verify eller npm cache clean först?
Kör alltid npm cache verify först. Det kontrollerar integriteten och städar bort data som inte behövs, samtidigt som giltigt cacheinnehåll behålls. npm cache clean --force är till för uppmätt platsbrist eller ett bekräftat cachefel.
Raderar en rensning av npm-cachen package-lock.json?
Nej. package.json och package-lock.json är projektfiler. npm v12 läser inte längre npm-shrinkwrap.json; om den är ett äldre projekts enda låsfil ska den byta namn till package-lock.json, inte raderas under cacheunderhåll. Skriv aldrig över en befintlig package-lock.json.
Källor