Zarządzanie aktualizacjami zależności w projekcie Node.js

Ukończone

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 interfejsu npm shrinkwrap wiersza polecenia i jest podobny do package-lock.json. Główną różnicą między poleceniami jest to, że wersje pakietów określone w programie npm-shrinkwrap.json nie mogą być zastępowane przez użytkowników. Ponadto npm-shrinkwrap.json plik jest zgodny ze starszymi wersjami npm (wersja 2–4), natomiast package-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.jsonzamiast .package-lock.json Jednym z wyjątków, w których npm-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 i package-lock.json zgadzają się na regułę wersji, nie ma konfliktu. Jeśli na przykład package.json określa 1.x i package-lock.json określa wersję 1.4, zostanie zainstalowana wersja 1.4.
  • Jeśli package.json określa bardziej konkretną wersję, na 1.8.xprzykład , zastępuje package-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 to:

  1. npm run test: Przed rozpoczęciem tego procesu aktualizacji sprawdź, czy istniejące testy przeszły pomyślnie.
  2. npm audit: aby sprawdzić luki w zabezpieczeniach w bieżącej używanej wersji. Informacje z npm audit programu mogą zalecić aktualizację do wersji głównej. Jeśli istnieją jakieś zmiany powodujące niezgodność, należy dokładnie przejrzeć te zmiany.
  3. npm outdated: aby wyświetlić listę wszystkich nieaktualnych pakietów. To polecenie zawiera informacje w kolumnach Wanted (Poszukiwane), Latest (Najnowsze) i Location (Lokalizacja).
  4. 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.
  5. npm audit: sprawdź, czy nie ma krytycznych ani wysokich luk w zabezpieczeniach. Jeśli luki w zabezpieczeniach nadal istnieją, użyj npm update nazwy pakietu i wersji głównej zalecanej w pliku npm audit.
  6. npm run test Ponownie.
  7. Zaewidencjonuj swoje package.json i package-lock.json.