Slik tømmer du npm-cachen trygt på Mac

Skill npm-cachen fra prosjektfilene

npm bruker en delt, innholdsadressert cache for pakkenedlastinger og HTTP-data. Standardroten på macOS er ~/.npm, men konfigurasjonen kan peke et annet sted. node_modules er det installerte avhengighetstreet i ett prosjekt, mens package.json og package-lock.json beskriver prosjektet og den låste avhengighetsoppløsningen. Ingen av disse prosjektfilene er cache eller skal slettes under cachevedlikehold. npm-shrinkwrap.json er heller ikke cache; hvis den er prosjektets eneste låsefil og package-lock.json ikke finnes, endrer du filnavnet før en installasjon med npm v12 uten å overskrive en eksisterende fil.

Finn, kontroller og rydd den aktive cachen

Spør npm om den gjeldende plasseringen i stedet for å anta at ~/.npm er aktiv. npm config get cache viser stien for den aktuelle konfigurasjonen; mål akkurat denne stien med du -sh og noter den ledige plassen i macOS. npm cache verify kontrollerer cacheindeksen og alle cachedata, verifiserer integriteten og fjerner unødvendige data uten å forkaste alt gyldig innhold. Til vanlig vedlikehold er dette ofte nok.

1. Kjør npm --version og npm config get cache, og bekreft at stien npm skriver ut, er en cache og ikke en prosjektmappe.
2. Mål nøyaktig denne stien med du -sh "$(npm config get cache)", noter den ledige plassen i macOS, og la package.json og låsefilen stå uendret.
3. Stopp aktive npm install-, npm ci-, npm exec- og publiseringsprosesser, kjør npm cache verify uten --force, og ta vare på sammendraget og eventuelle feil.
4. Kjør npm cache clean --force bare hvis den målte plassbesparelsen er relevant, og alle nødvendige artefakter kan hentes igjen; ikke endre node_modules, package.json eller noen låsefil samtidig.
5. Kjør npm cache verify på nytt, mål samme sti og den ledige plassen igjen, og test ett representativt prosjekt med uendret låsefil, bygg og tester.

Gi aldri en ubekreftet sti til rm -rf, og kombiner aldri cachetømming med sletting eller nyoppretting av en låsefil. npm v12 leser ikke npm-shrinkwrap.json; endre filnavnet til package-lock.json bare når den er prosjektets eneste låsefil og målfilen ikke finnes. Overskriv aldri en eksisterende package-lock.json.

Aksepter nettverks- og gjenopprettingskostnaden

Kjør npm cache clean --force bare når den målte cachen er stor nok til å ha betydning, du trenger plassen nå, og pakkene kan lastes ned på nytt. Kommandoen tømmer den konfigurerte cachen, ikke node_modules eller låsefiler. Senere installasjoner og npm ci kan ta lengre tid eller mislykkes uten internett, privat pakkeregister, Git-tilgang, proxy eller gyldig pålogging. En låsefil bevarer valget av avhengigheter, ikke pakkebytene; kritiske eller utgåtte artefakter hører hjemme i et ordentlig register eller arkiv. Ikke gjør force til en permanent npm-innstilling.

Kontroller resultatet og avgrens feilen

Be npm om cachestien på nytt etter oppryddingen, mål samme plassering og sammenlign den faktisk ledige plassen i macOS. Test ett representativt prosjekt med uendret package.json og låsefil, og kjør prosjektets bygg og tester. Hvis den samme feilen kommer tilbake, må du ikke tømme cachen gjentatte ganger: ERESOLVE, manglende pålogging, 404-feil, proxy- eller sertifikatfeil, inkompatible Node.js-versjoner, native bygg og livsløpsskript krever en egen diagnose. AskClean finner standardcachen ~/.npm; en egendefinert npm-cache må kontrolleres med npm config get cache.

Slettingsgrenser og gjenopprettingskostnader

Finn og mål den aktive npm-cachen, kontroller den først, og tøm den bare når plassen faktisk trengs og du godtar nye nedlastinger.

Vanlige spørsmål