Jak usunąć node_modules na Macu bez utraty projektu
Zespół AskClean · Zaktualizowano 2026-11-02
Katalog node_modules można usunąć, jeśli package.json, właściwy lockfile, źródła i konfiguracja są zabezpieczone, a wszystkie zależności nadal da się pobrać lub zbudować. Najpierw zmierz jeden projekt i zatrzymaj korzystające z niego procesy, potem przenieś tylko node_modules do Kosza, odtwórz zależności właściwym menedżerem pakietów i sprawdź kompilację, testy oraz uruchomienie. Nie myl node_modules ze współdzieloną pamięcią podręczną pobrań npm — mają inne lokalizacje, przeznaczenie i koszt odtworzenia.
Oddziel zależności od projektu i pamięci podręcznej npm
node_modules to zainstalowane drzewo zależności konkretnego projektu, a nie jego źródła ani współdzielona pamięć podręczna pobrań npm w ~/.npm. Możesz odtworzyć ten katalog tylko z zachowanych package.json, lockfile, plików workspace, .npmrc, łatek i konfiguracji. Usunięcie katalogu nadrzędnego, źródeł albo lockfile przekracza granicę bezpiecznego czyszczenia; wyczyszczenie pamięci podręcznej npm jest osobną operacją o skutkach dla wielu projektów.
Sprawdź możliwość odtworzenia i rozmiar
W katalogu głównym projektu uruchom pwd, upewnij się, że są w nim package.json i oczekiwany lockfile, oraz sprawdź git status i pole packageManager. Od wersji 12 npm nie odczytuje już npm-shrinkwrap.json: jeśli jest to jedyny lockfile w starym projekcie, zmień jego nazwę na package-lock.json. Nigdy nie nadpisuj istniejącego package-lock.json; gdy projekt zawiera oba pliki, porównaj i uzgodnij je osobno. Sprawdź też dostęp do prywatnych rejestrów, zależności Git i file:, lokalnych workspace’ów, zewnętrznych plików oraz narzędzi do kompilacji modułów natywnych. Rozmiar zmierz w Terminalu poleceniem du -sh ./node_modules; lockfile utrwala rozstrzygnięte wersje zależności, lecz nie jest kopią pakietów ani gwarancją ich dostępności.
- Uruchom pwd, sprawdź package.json, właściwy lockfile i konfigurację workspace’u, a następnie zabezpiecz wszystkie zmiany widoczne w git status.
- Sprawdź pole packageManager, wersję narzędzia oraz dostęp do prywatnych rejestrów, Git, zależności lokalnych i zewnętrznych artefaktów.
- Uruchom du -sh ./node_modules, zapisz rozmiar i zatrzymaj wszystkie procesy korzystające z katalogu.
- Przenieś tylko node_modules tego projektu do Kosza i odtwórz je z katalogu głównego właściwym, przypiętym menedżerem pakietów.
- Uruchom udokumentowaną kompilację, testy i aplikację; opróżnij Kosz dopiero po powodzeniu i ponownie sprawdź wolne miejsce.
Nie traktuj node_modules jako bezwarunkowo odtwarzalnego. Lokalna poprawka, wycofany pakiet prywatny, niedostępny commit Git, brakujący plik workspace lub natywny zestaw narzędzi mogą sprawić, że sam lockfile nie wystarczy.
Usuń tylko jeden potwierdzony katalog
Zatrzymaj serwery deweloperskie, testy w trybie watch, edytory wykonujące instalację i menedżery pakietów. Sprawdź, czy zaznaczony element nazywa się node_modules, a folder nadrzędny to właściwy projekt, po czym przenieś do Kosza wyłącznie ten katalog. rm -rf ./node_modules omija Kosz i jest nieodwracalne, dlatego nie buduj masowego polecenia z niezweryfikowanego wyniku find, wzorca glob ani zmiennej. Nie czyść przy tym lockfile, pamięci podręcznej npm ani współdzielonego magazynu menedżera pakietów. AskClean usuwa potwierdzone foldery trwale, z pominięciem Kosza, więc jeśli chcesz mieć możliwość powrotu, przenieś katalog do Kosza samodzielnie w Finderze.
Odtwórz właściwym narzędziem i zweryfikuj projekt
Dla npm, gdy package-lock.json jest obowiązującym lockfile, użyj npm ci. W innych projektach zastosuj przypiętą wersję menedżera i tryb, który nie zmienia lockfile, na przykład pnpm install --frozen-lockfile, yarn install --immutable, yarn install --frozen-lockfile albo bun install --frozen-lockfile. Monorepo odtwarzaj z katalogu głównego zgodnie z jego konfiguracją workspace. Dopiero po udanej instalacji, kompilacji, testach i uruchomieniu opróżnij Kosz. Błąd może wymagać przywrócenia katalogu oraz naprawy poświadczeń, sieci, wersji środowiska lub zestawu narzędzi; ponowne pobranie i kompilacja mogą być kosztowne.
Co można usunąć i jaki jest koszt odtworzenia
Znajdź duże katalogi node_modules na Macu, chroń źródła i lockfile, usuwaj zależności projekt po projekcie i instaluj je ponownie przez npm, pnpm, Yarn lub Bun.
| Element lub decyzja | Gdzie sprawdzić | Skutek usunięcia |
|---|---|---|
| Oddziel zależności od projektu i pamięci podręcznej npm | projekt/node_modules | node_modules to zainstalowane drzewo zależności konkretnego projektu, a nie jego źródła ani współdzielona pamięć podręczna pobrań npm w ~/.npm. |
| Sprawdź możliwość odtworzenia i rozmiar | package.json + lockfile + konfiguracja workspace | W katalogu głównym projektu uruchom pwd, upewnij się, że są w nim package.json i oczekiwany lockfile, oraz sprawdź git status i pole packageManager. |
| Usuń tylko jeden potwierdzony katalog | Kosz / ponowna instalacja przez menedżer pakietów | Zatrzymaj serwery deweloperskie, testy w trybie watch, edytory wykonujące instalację i menedżery pakietów. |
| Odtwórz właściwym narzędziem i zweryfikuj projekt | kompilacja + testy + uruchomienie aplikacji | Dla npm, gdy package-lock.json jest obowiązującym lockfile, użyj npm ci. |
FAQ
Czy usunięcie node_modules jest bezpieczne?
Zwykle tak, jeśli zachowasz źródła, konfigurację, package.json i właściwy lockfile oraz potwierdzisz dostępność wszystkich zależności. Projekt nie będzie działać do zakończenia ponownej instalacji.
Czy razem z node_modules usuwać package-lock.json?
Nie. Plik package-lock.json utrwala rozstrzygnięte wersje zależności i jest podstawą działania npm ci. Od wersji 12 npm nie odczytuje już npm-shrinkwrap.json; jeśli to jedyny lockfile w starym projekcie, zmień jego nazwę na package-lock.json, ale nigdy nie nadpisuj istniejącego pliku o tej nazwie.
Czy node_modules i pamięć podręczna npm to to samo?
Nie. node_modules należy do jednego projektu, a ~/.npm to współdzielona pamięć pobrań. Usunięcie pierwszego wymusza odtworzenie projektu, a wyczyszczenie drugiego zwiększa koszt kolejnych instalacji w wielu projektach.
Źródła