większość nowoczesnych usług i aplikacji ma masę zależności, które żyją w stale rosnącym folderze node-modules. Generalnie wiele z tych bibliotek jest aktywnie utrzymywanych, zmienianych i aktualizowanych. Jeśli Twoje zależności są źle zarządzane, możesz szybko znaleźć się w piekle zależności.

jeśli nie znasz npm, sprawdź to tutaj przed przeczytaniem na

Grocery zakupy spożywcze

podczas uruchamiania aplikacji węzła, jednym z pierwszych kroków jest uruchomienie npm install. Kiedy to uruchomisz, node sprawdzi, czy w bazie Twojego projektu znajduje się plik o nazwie package.json. Jeśli ten plik zostanie znaleziony, użyje sekcji dependency jako rodzaju „listy zakupów spożywczych”, aby zebrać” składniki ” (bity kodu), których wymaga Twoja aplikacja.

„Sklep Spożywczy” w tym przypadku jest czymś, co npm nazywa registry. Domyślnie aplikacja node będzie szukać tych pakietów w publicznym rejestrze npm, gdzie będzie wszystko, czego potrzebujesz(można tworzyć prywatne rejestry dla zastrzeżonego kodu i innych rzeczy). Jeśli pakiet znajduje się w rejestrze, node umieszcza ten „składnik” w katalogu node_modules W bazie Twojego projektu.

ważne jest, aby pamiętać, że pakiety, których potrzebujesz, mogą mieć własną „listę zakupów”(pakiet.json), a wszystkie te zagnieżdżone zależności muszą zostać rozwiązane, zanim Twoja aplikacja przejdzie do następnej zależności w swoim własnym pakiecie.json.

⬆️ wersje, 🥕 karetki i Wild wieloznaczne

wersje Twoich zależności są zazwyczaj podobne do v1.3.5. Nazywa się to wersjonowaniem semantycznym lub semver. W semverze liczby oznaczają zmiany w kodzie o różnym nasileniu – MAJOR.MINOR.PATCH.
z ich dokumentów –

wersja główna, gdy wprowadzasz niezgodne zmiany API,
wersja podrzędna, gdy dodajesz funkcjonalność w sposób zgodny wstecz, i
wersja łatana, gdy naprawiasz błędy zgodne wstecz.

Mając to na uwadze, wiele osób chce automatycznie aktualizować swoją aplikację o nowe, świeże rzeczy, które mogą mieć ich zależności w nowszych, niełamliwych zmianach.

prefiks tyldy ~ da ci wszelkie nowe aktualizacje PATCH, ale nie większe ani mniejsze. Tak więc ~1.3.1 może zainstalować 1.3.9, ale nie 1.4.0

prefiks z caret ^ da ci nowe wersje PATCH i MINOR, ale nie główne. Więc ^1.3.1 może zainstalować 1.4.9 ale nie 1.5.0

spójrzmy na przykładowe drzewo zależności kodu:

my-breakfast | | milk | |coffee-script 

ok, bardziej jak kij, ale miejmy nadzieję, że łańcuch zależności jest jasny. Nasza paczka.json wymaga wersji v0.5.0 w szczególności milk, ale mleko wymaga coffee-script gdziekolwiek od 0.9.6 – 1.0.0. npm install jest uruchomiony, rozwijamy naszą aplikację, wszystko jest hunky-dory.

📼 teraz przewińmy do przodu o 2 miesiące. Ktoś znajdzie Twój projekt i chce wnieść swój wkład. Oni fork i klon repo, uruchomić npm install, aaaaand to nie działa. „Ale zadziałało na mojej maszynie!”płaczesz. Gdy twój współpracownik zainstalował Moduły node, miały one zagwarantowaną określoną wersję milk, ale dostały inną wersję coffee-script, ponieważ milk jest pakietem.json używał semvera.

Setting Ustawianie zależności w kamieniu

jednym z rozwiązań tego problemu jest użycie pliku package-lock.json. Ten plik daje ci bardzo szczegółową kontrolę nad wersjami każdej zainstalowanej zależności. Jeśli twój package.json jest jak lista zakupów, to twój package-lock.json jest jak budżet. Możesz zjeść płatki, ale to będzie Marka sklepu zamiast Cap ’ n Crunch. Ta specyfika przebiega przez całą drogę w dół każdej gałęzi drzewa zależności. Musisz mieć package.json, jeśli chcesz użyć pliku blokady (package.json robi o wiele więcej niż tylko zarządzanie zależnościami, to jest po prostu głównym tematem tego postu).

osobiście uważam, że zawsze powinien być używany plik package-lock.json (w nowszych wersjach npm jest on generowany automatycznie). Dzięki temu wszystko staje się bardziej niezawodne w różnych środowiskach i wdrożeniach. Oto kilka ostatnich małych bryłek, które mam nadzieję pomóc, jeśli chodzi o zależności:

• npm install --save automatycznie zaktualizuje Twój plik blokady i pakiet.json z tą paczką.
• npm ci zamiast tylko npm install automatycznie przebuduje Moduły węzła i zbuduje je z pliku blokującego. Jest to bardzo pomocne polecenie dla CI / CD i ogólnie najlepiej używać w parze z plikiem blokującym.
• w przypadku większych projektów i bardzo solidnych zależności, sprawdź docker i kontenery. Może działać prawie jak maszyna wirtualna, która doskonale Zawiera Twój kod i jego zależności i jest klonowana w celu promowania w różnych środowiskach. Mam nadzieję, że skończysz z mniejszymi problemami typu „to działało na mojej maszynie”.