Zarządzanie aktualizacjami zależności w projekcie Node.js
Jako deweloper w firmie Tailwind Traders ważne jest, aby nasze pakiety były aktualne. Dzięki temu będziemy korzystać z najnowszych funkcji i poprawek. Pomaga to również uniknąć luk w zabezpieczeniach. W tej lekcji dowiesz się, jak zarządzać zależnościami w projekcie Node.js. Dowiesz się, jak aktualizować pakiety, używać semantycznej obsługi wersji i zarządzać problemami z zabezpieczeniami.
Zagadnienia dotyczące aktualizacji pakietu
Przed zaktualizowaniem pakietu rozważ następujące kwestie:
- Typ aktualizacji: dowiedz się, czy jest to poprawka pomocnicza, nowa funkcja lub główna zmiana, która może spowodować przerwanie kodu. Semantyczne przechowywanie wersji może pomóc w zidentyfikowaniu tego.
- Konfiguracja projektu: upewnij się, że projekt ma otrzymywać tylko żądane aktualizacje, aby uniknąć nieoczekiwanych zmian.
- Zabezpieczenia: Bądź świadomy potencjalnych luk w zabezpieczeniach. Funkcja inspekcji narzędzia npm umożliwia identyfikowanie i aktualizowanie problematycznych pakietów.
- Testowanie: upewnij się, że testy kończą się powodzeniem po aktualizacji. Jeśli nie masz testów, rozważ dodanie ich. Aplikacja może zachowywać się inaczej po aktualizacji, a testy sprawdzają poprawność zachowania.
Semantyczne przechowywanie wersji w celu zdefiniowania zachowania aktualizacji
Semantyczne przechowywanie wersji jest kluczowym standardem w tworzeniu oprogramowania. Jest to niezbędne zarówno w przypadku publikowania, jak i używania pakietów npm. Pomaga zarządzać ryzykiem aktualizacji, wskazując typ zmian w nowej wersji. Numer wersji zawiera konkretne sekcje odzwierciedlające te zmiany:
Typ wersji | Position | Składnia | Co się stanie | Podejście aktualizacji |
---|---|---|---|---|
Istotne | 1. | x.0.0 lub * | Zmiany z 1.0.0 do 2.0.0 wskazują zmiany powodujące niezgodność. Korekty kodu mogą być konieczne. | Wygodne w przypadku natychmiastowych aktualizacji najnowszej wersji głównej, uznając potencjalne zmiany kodu. |
Nieistotne | 2. | 1.x.1 lub ^ | Zmiany z 1.2.9 na 1.3.0 wprowadza nowe funkcje. Istniejący kod powinien nadal działać. Aktualizacje są zwykle bezpieczne. | Otwórz nowe funkcje, ale nie ulega zmianom powodującym niezgodność. |
Patch | 3. | 1.1.x lub ~ | Zmiany z 1.0.7 na 1.0.8 średnie poprawki błędów. Aktualizacje powinny być bezpieczne. | Akceptowanie poprawek błędów. |
W przypadku małych projektów Node.js można swobodnie aktualizować do najnowszych wersji. Jednak w przypadku większych projektów aktualizacje wymagają starannego przemyślenia i nie zawsze są automatyczne. Ogólnie rzecz biorąc, aktualizowanie mniejszych zależności z mniejszą liczbą własnych zależności ułatwia proces.
Przed zaktualizowaniem co najmniej jednej zależności należy skonfigurować package.json
plik, aby uzyskać przewidywalne zachowanie podczas uruchamiania npm update <name of dependency>
polecenia. Node.js używa zestawu symboli, który umożliwia zdefiniowanie sposobu aktualizowania pakietów.
Aktualizowanie pakietu przy użyciu interfejsu wiersza polecenia npm
Pakiet można zainstalować przy użyciu polecenia lub update
w narzędziu install
npm. Te polecenia są teraz w większości zamienne. Aby zaktualizować pakiet, zazwyczaj używasz:
- Najnowsza wersja:
npm update <package name>@latest
. - Określona wersja:
npm update <package name>@<optional version number>
.
Proces aktualizacji zależy od dwóch czynników:
- Argument wersji: jeśli numer wersji jest określony w poleceniu
npm update
, narzędzie npm pobiera i instaluje daną wersję. - Wpis pliku manifestu:
package.json
plik zawiera reguły aktualizowania zależności. Na przykład oznacza,"dependencyName": "1.1.x"
że narzędzie npm pobierze wersję zgodną z tym wzorcem.
Omówienie przechowywania wersji
Trzy pliki kontrolują przechowywanie wersji zależności:
package.json
: Ten plik definiuje wersję pakietu, którego chcesz użyć. Jest to plik manifestu projektu. Zawiera metadane projektu, w tym zależności.package-lock.json
: Ten plik opisuje dokładne drzewo, które zostało wygenerowane, tak aby kolejne instalacje mogły generować identyczne drzewa, niezależnie od aktualizacji zależności pośrednich. Ten plik ma zostać zatwierdzony w repozytoriach źródłowych.shrinkwrap.json
: Ten plik jest tworzony przez polecenie interfejsunpm shrinkwrap
wiersza polecenia i jest podobny dopackage-lock.json
. Główną różnicą między poleceniami jest to, że wersje pakietów określone w programienpm-shrinkwrap.json
nie mogą być zastępowane przez użytkowników. Ponadtonpm-shrinkwrap.json
plik jest zgodny ze starszymi wersjami npm (wersja 2–4), natomiastpackage-lock.json
jest zgodny z programem npm w wersji 5 lub nowszej. W związku z tym może się okazać, że podczas obsługi starszych baz kodu można znaleźćnpm-shrinkwrap.json
. Większość deweloperów będzie używaćnpm-shrinkwrap.json
zamiast .package-lock.json
Jednym z wyjątków, w którychnpm-shrinkwrap.json
preferowane jest stosowanie globalnych instalacji demonów i narzędzi wiersza polecenia, w których deweloperzy chcą upewnić się, że zainstalowane są dokładne wersje określonych pakietów.
Przykładowe określanie wersji pakietu
Rozważmy scenariusz, w którym używasz wersji 1.2 w kodzie, a następnie wydano wersję 1.4, powodując niezgodność kodu. Jeśli ktoś zainstaluje aplikację w tym momencie, otrzyma aplikację niefunkcjonacyjną. Jeśli jednak istnieje package-lock.json
plik określający wersję 1.2, zostanie zainstalowana ta wersja.
Oto przykład określania, która wersja pakietu jest zainstalowana:
package.json
Jeśli pliki ipackage-lock.json
zgadzają się na regułę wersji, nie ma konfliktu. Jeśli na przykładpackage.json
określa1.x
ipackage-lock.json
określa wersję 1.4, zostanie zainstalowana wersja 1.4.- Jeśli
package.json
określa bardziej konkretną wersję, na1.8.x
przykład , zastępujepackage-lock.json
plik, który określa starszą wersję 1.4. W takim przypadku zostanie zainstalowana wersja 1.8.0 lub nowsza wersja poprawki, jeśli jest dostępna.
Znajdowanie i aktualizowanie nieaktualnych pakietów za pomocą nieaktualnego narzędzia npm
Polecenie służy do identyfikowania npm outdated
pakietów, które mają dostępne nowsze wersje. Po uruchomieniu zostanie wyświetlona lista tych nieaktualnych pakietów:
Package Current Wanted Latest Location Depended by
lodash 1.0.0 1.0.0 4.17.19 lock-test main-code-file
node-fetch 1.2.0 1.2.0 2.6.0 lock-test function-code-file
Kolumny w danych wyjściowych obejmują:
Kolumna | opis |
---|---|
Pakiet | Nieaktualny pakiet. |
Bieżąca | Bieżąca zainstalowana wersja pakietu. |
Chciał | Najnowsza wersja zgodna ze wzorcem package.json semantycznym określonym w pliku. |
Najnowsze | Najnowsza wersja pakietu. |
Lokalizacja | Lokalizacja zależności pakietu. Polecenie outdated przeszukiwa wszystkie zainstalowane pakiety w różnych node_modules folderach. |
Zależne od | Pakiet, który ma zależność. |
Zarządzanie problemami z zabezpieczeniami przy użyciu inspekcji npm
Za każdym razem, gdy instalujesz lub aktualizujesz pakiet, otrzymujesz odpowiedź dziennika, która informuje o tym, jaka wersja została zainstalowana i czy występują jakiekolwiek luki w zabezpieczeniach. Dziennik zawiera listę luk w zabezpieczeniach. Jeśli masz jakiekolwiek krytyczne lub wysokie luki w zabezpieczeniach, należy zaktualizować pakiet.
Przykładem odpowiedzi dziennika jest:
+ lodash@1.3.1
added 1 package from 4 contributors and audited 1 package in 0.949s
found 3 vulnerabilities (1 low, 2 high)
run `npm audit fix` to fix them, or `npm audit` for details
Aby rozwiązać problem i zastosować aktualizację, możesz uruchomić npm audit
polecenie . To polecenie wyświetla listę każdej luki w zabezpieczeniach.
Polecenie npm audit fix
próbuje rozwiązać luki w zabezpieczeniach przez uaktualnienie do wersji pomocniczej, w której problem nie istnieje. Może to być jednak niedostępne, jeśli poprawka jest rzeczywiście w następnej wersji głównej.
W takich przypadkach może być konieczne użycie elementu npm audit fix --force
, co może spowodować wprowadzenie zmian powodujących niezgodność przez aktualizację do wersji głównej. Uruchomienie tego polecenia jest decyzją, którą należy dokładnie podjąć. Należy pamiętać o zmianach powodujących niezgodność i użyć npm update
ich do zaktualizowania kodu, w tym luk w zabezpieczeniach.
Luka w zabezpieczeniach jest wadą kodu, która może zostać wykorzystana przez osoby atakujące do wykonywania złośliwych akcji, potencjalnie zakłócających działanie danych i systemów. Niezwykle ważne jest szybkie rozwiązanie tych luk w zabezpieczeniach.
Biorąc pod uwagę częste odnajdywanie luk w zabezpieczeniach, usługa GitHub ma funkcję, która skanuje repozytoria i automatycznie tworzy żądania ściągnięcia sugerujące uaktualnienia do bezpieczniejszych wersji. Regularne uruchamianie npm audit
to dobre rozwiązanie do identyfikowania i naprawiania luk w zabezpieczeniach, co przyczynia się do ogólnego bezpieczeństwa projektu.
Zalecany przepływ pracy aktualizacji
Zalecany przepływ pracy aktualizacji to:
npm run test
: Przed rozpoczęciem tego procesu aktualizacji sprawdź, czy istniejące testy przeszły pomyślnie.npm audit
: aby sprawdzić luki w zabezpieczeniach w bieżącej używanej wersji. Informacje znpm audit
programu mogą zalecić aktualizację do wersji głównej. Jeśli istnieją jakieś zmiany powodujące niezgodność, należy dokładnie przejrzeć te zmiany.npm outdated
: aby wyświetlić listę wszystkich nieaktualnych pakietów. To polecenie zawiera informacje w kolumnach Wanted (Poszukiwane), Latest (Najnowsze) i Location (Lokalizacja).- Zaktualizuj za pomocą polecenia
npm update
:- W przypadku mniejszych projektów (kilka zależności w elemencie
package.json
: możesz spróbowaćnpm update
zaktualizować wszystkie zależności, a następnie uruchomić testy. - W przypadku większych projektów (z wieloma zależnościami w programie
package.json
: zaktualizuj pojedynczy pakiet lub rodzinę pakietów (na przykład Next.js i React), a następnie uruchom testy.
- W przypadku mniejszych projektów (kilka zależności w elemencie
npm audit
: sprawdź, czy nie ma krytycznych ani wysokich luk w zabezpieczeniach. Jeśli luki w zabezpieczeniach nadal istnieją, użyjnpm update
nazwy pakietu i wersji głównej zalecanej w plikunpm audit
.npm run test
Ponownie.- Zaewidencjonuj swoje
package.json
ipackage-lock.json
.