Jak bezpiecznie wyczyścić pamięć podręczną npm na Macu
Zespół AskClean · Zaktualizowano 2026-08-05
Uruchom npm config get cache, zmierz wskazany katalog i przed usuwaniem wykonaj npm cache verify. Po npm cache clean --force późniejsze instalacje będą ponownie pobierać pakiety, ale polecenie nie usuwa node_modules, package.json ani lockfile. Pełne czyszczenie ma sens dopiero przy zmierzonym braku miejsca lub potwierdzonym błędzie samej pamięci podręcznej.
Rozróżnij pamięć podręczną, zależności i pliki projektu
npm przechowuje współdzielone pobrania w magazynie adresowanym zawartością, domyślnie w ~/.npm, lecz konfiguracja może wskazywać inną ścieżkę. node_modules jest zainstalowanym drzewem zależności jednego projektu, natomiast package.json i package-lock.json opisują jego stan — żaden z tych elementów nie jest pamięcią podręczną. npm v12 nie odczytuje już npm-shrinkwrap.json: jeśli jest to jedyny lockfile w starym projekcie, zmień nazwę tego identycznie sformatowanego pliku na package-lock.json. Nie nadpisuj istniejącego package-lock.json; gdy są oba pliki, porównaj i uzgodnij je jako osobną zmianę.
Znajdź, zmierz i najpierw zweryfikuj
Sprawdź npm --version i uruchom npm config get cache zamiast zakładać, że używane jest ~/.npm. Skopiuj zwróconą ścieżkę, potwierdź, że wskazuje pamięć podręczną, ujmij ją w cudzysłów, jeśli zawiera spacje, i zmierz przez du -sh. Zatrzymaj aktywne npm install, npm ci, npm exec i npm publish, po czym uruchom npm cache verify. Polecenie sprawdza integralność i usuwa niepotrzebne dane, zachowując poprawną zawartość. Zmierz ponownie; rutynowa konserwacja często nie wymaga niczego więcej.
- Uruchom npm --version oraz npm config get cache i upewnij się, że wynik wskazuje pamięć podręczną, a nie katalog projektu.
- Zmierz dokładnie zwróconą ścieżkę przez du -sh, ujmując ją w cudzysłów, jeśli zawiera spacje, i zapisz dostępne miejsce na Macu.
- Zatrzymaj procesy npm, zachowaj package.json i lockfile bez zmian, a następnie uruchom npm cache verify.
- Jeśli pełne czyszczenie jest nadal uzasadnione i akceptujesz ponowne pobrania, uruchom npm cache clean --force.
- Ponownie zweryfikuj i zmierz pamięć podręczną, sprawdź wolne miejsce oraz zbuduj jeden projekt bez zmiany grafu zależności.
Nie wklejaj niezweryfikowanej ścieżki do rm -rf. Ten proces nie wymaga ręcznego usuwania rekursywnego, a pomyłka w konfiguracji mogłaby objąć projekt albo katalog domowy.
Pełne czyszczenie wykonuj tylko świadomie
npm cache clean --force jest uzasadnione, gdy pamięć podręczna rzeczywiście zajmuje potrzebne miejsce albo npm cache verify potwierdził nierozwiązany problem tej warstwy. --force jest wymagane, ponieważ pełne usunięcie zwykle nie jest potrzebne; nie zapisuj opcji force jako ustawienia globalnego npm. Polecenie usuwa współdzielone pobrania, więc następne instalacje będą wolniejsze, wymagają sieci, poświadczeń i dostępnych artefaktów, a praca offline może przestać być możliwa. Nie łącz tego z usuwaniem lockfile ani node_modules.
Sprawdź odzyskane miejsce i przyczynę błędu
Po czyszczeniu ponownie uruchom npm config get cache, opcjonalnie npm cache verify, zmierz tę samą ścieżkę i rzeczywiste wolne miejsce w macOS. Przetestuj reprezentatywny projekt z niezmienionymi package.json i lockfile. Jeśli błąd wraca, nie powtarzaj czyszczenia: przyczyną może być uwierzytelnianie w rejestrze, proxy, sieć, niedostępna wersja, wymagania Node.js, konflikt zależności równorzędnych, kompilacja natywna lub skrypt cyklu życia. Pamięć podręczna nie jest trwałym archiwum pakietów; krytyczne artefakty przechowuj w rejestrze lub kopii zapasowej.
Co można usunąć i jaki jest koszt odtworzenia
Znajdź i zmierz aktywną pamięć podręczną npm, najpierw ją zweryfikuj, a pełne czyszczenie wykonaj tylko po ocenie kosztu ponownego pobierania.
| Element lub decyzja | Gdzie sprawdzić | Skutek usunięcia |
|---|---|---|
| Rozróżnij pamięć podręczną, zależności i pliki projektu | npm config get cache | npm przechowuje współdzielone pobrania w magazynie adresowanym zawartością, domyślnie w ~/.npm, lecz konfiguracja może wskazywać inną ścieżkę. node_modules jest zainstalowanym drzewem zależności jednego projektu, natomiast package.json i package-lock.json opisują jego stan — żaden z tych elementów nie jest pamięcią podręczną. npm v12 nie odczytuje już npm-shrinkwrap.json: jeśli jest to jedyny lockfile w starym projekcie, zmień nazwę tego identycznie sformatowanego pliku na package-lock.json. Nie nadpisuj istniejącego package-lock.json; gdy są oba pliki, porównaj i uzgodnij je jako osobną zmianę. |
| Znajdź, zmierz i najpierw zweryfikuj | npm cache verify | Sprawdź npm --version i uruchom npm config get cache zamiast zakładać, że używane jest ~/.npm. Skopiuj zwróconą ścieżkę, potwierdź, że wskazuje pamięć podręczną, ujmij ją w cudzysłów, jeśli zawiera spacje, i zmierz przez du -sh. Zatrzymaj aktywne npm install, npm ci, npm exec i npm publish, po czym uruchom npm cache verify. Polecenie sprawdza integralność i usuwa niepotrzebne dane, zachowując poprawną zawartość. Zmierz ponownie; rutynowa konserwacja często nie wymaga niczego więcej. |
| Pełne czyszczenie wykonuj tylko świadomie | npm cache clean --force | npm cache clean --force jest uzasadnione, gdy pamięć podręczna rzeczywiście zajmuje potrzebne miejsce albo npm cache verify potwierdził nierozwiązany problem tej warstwy. --force jest wymagane, ponieważ pełne usunięcie zwykle nie jest potrzebne; nie zapisuj opcji force jako ustawienia globalnego npm. Polecenie usuwa współdzielone pobrania, więc następne instalacje będą wolniejsze, wymagają sieci, poświadczeń i dostępnych artefaktów, a praca offline może przestać być możliwa. Nie łącz tego z usuwaniem lockfile ani node_modules. |
| Sprawdź odzyskane miejsce i przyczynę błędu | instalacja + sprawdzenie pracy offline/rejestru prywatnego | Po czyszczeniu ponownie uruchom npm config get cache, opcjonalnie npm cache verify, zmierz tę samą ścieżkę i rzeczywiste wolne miejsce w macOS. Przetestuj reprezentatywny projekt z niezmienionymi package.json i lockfile. Jeśli błąd wraca, nie powtarzaj czyszczenia: przyczyną może być uwierzytelnianie w rejestrze, proxy, sieć, niedostępna wersja, wymagania Node.js, konflikt zależności równorzędnych, kompilacja natywna lub skrypt cyklu życia. Pamięć podręczna nie jest trwałym archiwum pakietów; krytyczne artefakty przechowuj w rejestrze lub kopii zapasowej. |
FAQ
Czy lepiej uruchomić npm cache verify, czy npm cache clean --force?
Najpierw npm cache verify: sprawdza integralność i usuwa zbędne dane, nie wyrzucając poprawnych pobrań. npm cache clean --force zostaw na zmierzony brak miejsca lub potwierdzony problem pamięci podręcznej.
Czy czyszczenie pamięci podręcznej npm usuwa node_modules lub package-lock.json?
Nie. Pamięć podręczna jest współdzielonym magazynem pobrań, a node_modules, package.json i package-lock.json należą do projektu. Nie usuwaj ani nie przepisuj ich podczas tej operacji.
Dlaczego npm nadal zgłasza błąd po wyczyszczeniu pamięci podręcznej?
Błąd prawdopodobnie dotyczy innej warstwy: sieci, rejestru, poświadczeń, wersji Node.js, grafu zależności, kompilacji natywnej albo skryptu cyklu życia. Zachowaj pierwszy istotny komunikat i diagnozuj go zamiast ponownie usuwać poprawne pobrania.
Źródła