Co naprawdę siedzi w katalogu node_modules
Ś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ć.
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.gitignoreto absolutna podstawa. Zawartość odtwarzasz jedną komendą z plikupackage.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 produkcyjnymnpm ci --omit=devpominie 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.
Komentarze (6)
-
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 -
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 -
Ewa
Ostatni akapit powinien być pogrubiony dwa razy. Ludzie ciągną dziesiątki paczek i nikt nie patrzy, czyj to kod.
Odpowiedz