Jak usunąć node_modules na Macu bez utraty projektu
Zespół AskClean · Zaktualizowano 2026-08-05
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 i sprawdź kompilację, testy oraz uruchomienie.
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, potwierdź package.json i oczekiwany lockfile, sprawdź git status oraz pole packageManager. npm v12 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, zewnętrznych plików oraz narzędzi do kompilacji modułów natywnych. Rozmiar zmierz przez 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, potwierdź package.json, właściwy lockfile i konfigurację workspace, 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 jego rodzicem jest właściwy projekt, po czym przenieś wyłącznie ten katalog do Kosza. rm -rf ./node_modules omija Kosz i jest nieodwracalne, dlatego nie buduj masowego polecenia z niezweryfikowanego wyniku find, globu ani zmiennej. Nie czyść jednocześnie lockfile, pamięci podręcznej npm ani współdzielonego magazynu menedżera pakietów.
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, zachowaj źródła i lockfile, usuń zależności dla jednego projektu i bezpiecznie je odtwórz.
| 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. 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 | package.json + lockfile + konfiguracja workspace | W katalogu głównym projektu uruchom pwd, potwierdź package.json i oczekiwany lockfile, sprawdź git status oraz pole packageManager. npm v12 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, zewnętrznych plików oraz narzędzi do kompilacji modułów natywnych. Rozmiar zmierz przez du -sh ./node_modules; lockfile utrwala rozstrzygnięte wersje zależności, lecz nie jest kopią pakietów ani gwarancją ich dostępności. |
| 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. Sprawdź, czy zaznaczony element nazywa się node_modules, a jego rodzicem jest właściwy projekt, po czym przenieś wyłącznie ten katalog do Kosza. rm -rf ./node_modules omija Kosz i jest nieodwracalne, dlatego nie buduj masowego polecenia z niezweryfikowanego wyniku find, globu ani zmiennej. Nie czyść jednocześnie lockfile, pamięci podręcznej npm ani współdzielonego magazynu menedżera 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; 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. |
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. package-lock.json jest wejściem dla npm ci i utrwala rozstrzygnięte wersje zależności. npm v12 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