Narzędzia

Co naprawdę siedzi w katalogu node_modules

13 maja 2026 2 min czytania web-pc.pl 6 komentarzy

Świeży projekt, jedna komenda, a na dysku przybywa 200 MB i 30 tysięcy plików. Skąd to się bierze i czy jest się czym martwić.

Co naprawdę siedzi w katalogu node_modules

Jest taki żart, że node_modules to najcięższy obiekt we wszechświecie. Jak każdy dobry żart, ma solidną podstawę: potrafi zająć kilkaset megabajtów, mimo że twój własny kod waży kilkadziesiąt kilobajtów.

Zależności zależności

Instalujesz jedną paczkę. Ta paczka potrzebuje trzech innych. Każda z nich potrzebuje kolejnych czterech. Po pięciu takich poziomach masz kilkaset bibliotek, z których osobiście wybrałeś jedną.

To nie jest wada, tylko cena bardzo drobnego podziału na moduły. Ekosystem JavaScriptu poszedł w stronę małych, wyspecjalizowanych paczek — zamiast jednej wielkiej biblioteki masz sto malutkich, które składasz jak klocki. Zaletą jest to, że nie ciągniesz kodu, którego nie używasz. Wadą — że drzewo zależności rośnie w oczach.

Trzy praktyczne wnioski

  • Nie wrzucaj tego katalogu do repozytorium. Wpis node_modules/ w pliku .gitignore to absolutna podstawa. Zawartość odtwarzasz jedną komendą z pliku package.json.
  • Pilnuj pliku package-lock.json. To on gwarantuje, że u ciebie, u kolegi i na serwerze zainstalują się dokładnie te same wersje. Trzymaj go w repozytorium i nie usuwaj przy pierwszym konflikcie.
  • Rozróżniaj zależności produkcyjne i deweloperskie. Narzędzia do testów i budowania instaluj z opcją --save-dev. Na serwerze produkcyjnym npm ci --omit=dev pominie je i katalog schudnie o połowę.

Kilka komend, które porządkują sytuację

# co i dlaczego zostało zainstalowane
npm ls nazwa-paczki

# znane luki bezpieczeństwa w zależnościach
npm audit

# co ma nowsze wersje
npm outdated

# czysta, powtarzalna instalacja z pliku lock
npm ci

Ostatnia komenda jest szczególnie warta zapamiętania. npm install potrafi po drodze zaktualizować wersje, npm ci instaluje dokładnie to, co zapisano w pliku lock. Na serwerze i w automatycznym wdrożeniu zawsze używaj tej drugiej.

Czy jest się czym martwić

Rozmiar sam w sobie nie jest problemem — ten katalog nigdy nie trafia na serwer WWW ani do przeglądarki użytkownika. Do przeglądarki idzie dopiero paczka po zbudowaniu, zwykle kilkadziesiąt razy mniejsza.

Realny problem jest inny: każda zależność to cudzy kod, który uruchamiasz u siebie. Warto od czasu do czasu przejrzeć listę i zapytać, czy paczka do sprawdzania, czy liczba jest parzysta, naprawdę jest potrzebna.

Podziel się:

Komentarze (6)

  1. Kuba

    Różnica między npm install a npm ci to była dla mnie nowość. Wrzuciłem od razu do konfiguracji wdrożenia.

    Odpowiedz
  2. Kuba

    Różnica między npm install a npm ci to była dla mnie nowość. Wrzuciłem od razu do konfiguracji wdrożenia.

    Odpowiedz
  3. Ewa

    Ostatni akapit powinien być pogrubiony dwa razy. Ludzie ciągną dziesiątki paczek i nikt nie patrzy, czyj to kod.

    Odpowiedz