Dlaczego program „npm install” przepisuje pakiet-lock.json?

Niedawno zaktualizowałem do npm @ 5 . Mam teraz plik package-lock.json ze wszystkim z pliku package.json . Spodziewałbym się, że po uruchomieniu npm installwersje zależności zostaną wyciągnięte z pliku blokady, aby określić, co powinno zostać zainstalowane w moim katalogu node_modules . Dziwne jest to, że w rzeczywistości modyfikuje i przepisuje mój plik package-lock.json .

Na przykład w pliku blokady określono maszynopis w wersji 2.1.6 . Następnie po npm installpoleceniu zmieniono wersję na 2.4.1 . Wydaje się, że pokonuje to cały cel pliku blokady.

czego mi brakuje? Jak mogę zmusić npm do respektowania mojego pliku blokady?

Aktualizacja 3: Jak wskazują inne odpowiedzi, npm cipolecenie zostało wprowadzone w npm 5.7.0 jako dodatkowy sposób na szybkie i powtarzalne kompilacje w kontekście CI. Więcej informacji znajduje się w dokumentacji i blogu npm .

Aktualizacja 2: Problemem do aktualizacji i wyjaśnienia dokumentacji jest problem GitHub nr 18103 .

Aktualizacja 1: Zachowanie, które zostało opisane poniżej, zostało naprawione w npm 5.4.2: aktualnie planowane zachowanie jest opisane w numerze GitHub # 17979 .

Oryginalna odpowiedź: zachowanie programu package-lock.jsonzostało zmienione w npm 5.1.0, jak omówiono w numerze # 16866 . Zachowanie, które obserwujesz, jest najwyraźniej zamierzone przez npm od wersji 5.1.0.

Oznacza to, że package.jsonmoże to zastąpić package-lock.jsonza każdym razem, gdy zostanie znaleziona nowsza wersja dla zależności w package.json. Jeśli chcesz skutecznie przypiąć swoje zależności, musisz teraz określić wersje bez prefiksu, np. Musisz je zapisać jako 1.2.0zamiast ~1.2.0lub ^1.2.0. Następnie kombinacja package.jsoni package-lock.jsonda powtarzalne kompilacje. Żeby było jasne: package-lock.jsonsam nie blokuje już zależności poziomu root!

To, czy ta decyzja projektowa była dobra, czy nie, jest dyskusyjne, toczy się dyskusja wynikająca z tego zamieszania na GitHubie w numerze 17979 . (Moim zdaniem jest to wątpliwa decyzja; przynajmniej nazwa locknie jest już prawdą).

Jeszcze jedna uwaga: istnieje również ograniczenie dla rejestrów, które nie obsługują niezmiennych pakietów, na przykład gdy pobierasz pakiety bezpośrednio z GitHub zamiast npmjs.org. Więcej informacji można znaleźć w tej dokumentacji blokad opakowań .

Odkryłem, że będzie nowa wersja npm 5.7.1 z nowym poleceniem npm ci, które będzie instalować package-lock.jsontylko z

Nowa komenda npm ci instaluje się TYLKO z pliku blokady. Jeśli plik package.json i plik blokady nie są zsynchronizowane, zgłosi błąd.

Działa poprzez wyrzucenie modułów node_modules i odtworzenie ich od zera.

Oprócz zagwarantowania, że ​​dostaniesz tylko to, co znajduje się w pliku blokady, jest także znacznie szybszy (2x-10x!) Niż instalacja npm, jeśli nie zaczynasz od modułów node_module.

Jak sama nazwa wskazuje, spodziewamy się, że będzie to duży dar dla ciągłej integracji środowisk. Oczekujemy również, że ludzie, którzy wykonają wdrożenia produkcyjne z tagów git, zobaczą znaczne korzyści.

Użyj nowo wprowadzonego

npm ci

npm ci obiecuje największe korzyści dużym zespołom. Umożliwienie programistom „wylogowania się” z blokady pakietu sprzyja wydajniejszej współpracy między dużymi zespołami, a możliwość zainstalowania dokładnie tego, co znajduje się w pliku blokady, może potencjalnie zaoszczędzić dziesiątki, jeśli nie setki godzin programistów w miesiącu, uwalniając zespoły spędzać więcej czasu na budowaniu i wysyłaniu niesamowitych rzeczy.

Przedstawiamy npm ciszybsze, bardziej niezawodne kompilacje

Krótka odpowiedź:

• npm install honoruje pakiet-lock.json tylko wtedy, gdy spełnia wymagania określone w pakiecie.json.
• Jeśli nie spełnia tych wymagań, pakiety są aktualizowane, a pakiet-lock jest zastępowany.
• Jeśli wolisz kompilację, niż przepisz pakiet-lock, kiedy to się stanie, użyj npm ci.

Oto scenariusz, który może wyjaśniać różne rzeczy (Verified with NPM 6.3.0)

Deklarujesz zależność w pakiecie.json jak:

"depA": "^1.0.0"

Następnie zrobisz, npm installco wygeneruje pakiet-lock.json z:

"depA": "1.0.0"

Kilka dni później zostaje wydana nowsza, mniejsza wersja „depA”, powiedzmy „1.1.0”, a następnie spełnione są następujące warunki:

npm ci       # respects only package-lock.json and installs 1.0.0

npm install  # also, respects the package-lock version and keeps 1.0.0 installed 
             # (i.e. when package-lock.json exists, it overrules package.json)

Następnie ręcznie zaktualizuj plik package.json do:

"depA": "^1.1.0"

Następnie uruchom ponownie:

npm ci      # will try to honor package-lock which says 1.0.0
            # but that does not satisfy package.json requirement of "^1.1.0" 
            # so it would throw an error 

npm install # installs "1.1.0" (as required by the updated package.json)
            # also rewrites package-lock.json version to "1.1.0"
            # (i.e. when package.json is modified, it overrules the package-lock.json)

Użyj npm cipolecenia zamiast npm install.

„ci” oznacza „ciągłą integrację”.

Zainstaluje zależności projektu na podstawie pliku package-lock.json zamiast łagodnych zależności pliku package.json.

Będzie produkować identyczne kompilacje z członkami twojej drużyny, a także jest znacznie szybszy.

Możesz przeczytać więcej na ten temat w tym poście na blogu: https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

W przyszłości będziesz mógł użyć --from-lock-fileflagi (lub podobnej), aby zainstalować tylko z poziomu package-lock.jsonbez jej modyfikowania.

Będzie to przydatne w środowiskach CI itp., W których ważne są odtwarzalne kompilacje.

Zobacz https://github.com/npm/npm/issues/18286 w celu śledzenia funkcji.

Wygląda na to, że ten problem został rozwiązany w npm v5.4.2

https://github.com/npm/npm/issues/17979

(Przewiń w dół do ostatniego komentarza w wątku)

Aktualizacja

Naprawiono w wersji 5.6.0. W wersji 5.4.2 wystąpił błąd wieloplatformowy, który powodował, że problem nadal występował.

https://github.com/npm/npm/issues/18712

Aktualizacja 2

Zobacz moją odpowiedź tutaj: https://stackoverflow.com/a/53680257/1611058

npm ci to polecenie, którego powinieneś używać podczas instalowania istniejących projektów.

Prawdopodobnie masz coś takiego:

"typescript":"~2.1.6"

w twoim, package.jsonktóre npm aktualizuje do najnowszej mniejszej wersji, w twoim przypadku2.4.1

Edycja: Pytanie od OP

Ale to nie wyjaśnia, dlaczego „instalacja npm” zmienia plik blokady. Czy plik blokady nie służy do tworzenia odtwarzalnej kompilacji? Jeśli tak, niezależnie od wartości semver, powinien nadal używać tej samej wersji 2.1.6.

Odpowiedź:

Ma to na celu zablokowanie pełnego drzewa zależności. Powiedzmy, że typescript v2.4.1wymaga widget ~v1.0.0. Po zainstalowaniu npm łapie widget v1.0.0. Później inny programista (lub kompilacja CI) wykonuje instalację npm i pobiera, typescript v2.4.1ale widgetzostała zaktualizowana do widget v1.0.1. Teraz moduł węzła nie jest zsynchronizowany. Co to jestpackage-lock.json zapobiega.

Lub bardziej ogólnie:

Jako przykład rozważ

pakiet A:

{„name”: „A”, „version”: „0.1.0”, „dependencies”: {„B”: „<0.1.0”}}

pakiet B:

{„name”: „B”, „version”: „0.0.1”, „dependencies”: {„C”: „<0.1.0”}}

i pakiet C:

{„name”: „C”, „version”: „0.0.1”}

Jeśli są to jedyne wersje A, B i C dostępne w rejestrze, wówczas zainstaluje się normalna instalacja A npm:

A@0.1.0 - B@0.0.1 - C@0.0.1

Jeśli jednak B@0.0.2 zostanie opublikowany, wówczas zainstalowana zostanie nowa instalacja A npm:

A@0.1.0 - B@0.0.2 - C@0.0.1, zakładając, że nowa wersja nie zmodyfikowała zależności B. Oczywiście nowa wersja B mogłaby obejmować nową wersję C i dowolną liczbę nowych zależności. Jeśli takie zmiany są niepożądane, autor A może określić zależność od B@0.0.1. Jeśli jednak autor A i autor B nie są tą samą osobą, autor A nie może powiedzieć, że nie chce pobierać nowo opublikowanych wersji C, gdy B w ogóle się nie zmienił.

Pytanie operacyjne nr 2: Pokażę, czy rozumiem poprawnie. Mówisz, że plik blokady określa wersje drugorzędnych zależności, ale nadal opiera się na rozmytym dopasowaniu pliku package.json w celu ustalenia zależności najwyższego poziomu. Czy to jest dokładne?

Odpowiedź: Nie. Pakiet-lock blokuje całe drzewo pakietów, w tym pakiety główne opisane w package.json. Jeśli typescriptjest zablokowane 2.4.1w twoim package-lock.json, powinno tak pozostać, dopóki nie zostanie zmienione. I powiedzmy, że jutro typescriptwypuszcza wersję 2.4.2. Jeśli sprawdzę twój oddział i uruchomię npm install, npm przestrzega pliku blokady i instaluje 2.4.1.

Więcej na package-lock.json:

Pakiet-lock.json jest generowany automatycznie dla wszystkich operacji, w których npm modyfikuje drzewo modułów_węzła lub pakiet.json. Opisuje dokładnie wygenerowane drzewo, dzięki czemu kolejne instalacje mogą generować identyczne drzewa, niezależnie od pośrednich aktualizacji zależności.

Ten plik ma być przeznaczony do repozytoriów źródłowych i służy do różnych celów:

Opisz pojedynczą reprezentację drzewa zależności, tak aby członkowie zespołu, wdrożenia i ciągła integracja gwarantowali zainstalowanie dokładnie tych samych zależności.

Zapewnij użytkownikom możliwość „podróży w czasie” do poprzednich stanów modułów_węzła bez konieczności zatwierdzania samego katalogu.

Aby ułatwić lepszą widoczność zmian drzewa dzięki czytelnym różnicom kontroli źródła.

I zoptymalizuj proces instalacji, pozwalając npm na pomijanie powtarzających się rozdzielczości metadanych dla wcześniej zainstalowanych pakietów.

https://docs.npmjs.com/files/package-lock.json

Prawdopodobnie powinieneś użyć czegoś takiego

npm ci

Zamiast używać, npm install jeśli nie chcesz zmieniać wersji swojego pakietu.

Zgodnie z oficjalną dokumentacją zarówno zainstalować , jak npm installi npm cizależności, które są potrzebne do projektu.

Główną różnicą jest to, npm installże instaluje pakiety, biorąc je packge.jsonza odniesienie. Tam, gdzie w przypadku npm ci, instaluje pakiety, biorąc je package-lock.jsonza odniesienie, upewniając się, że za każdym razem instalowany jest dokładny pakiet.

Jest to otwarty problem na ich stronie github: https://github.com/npm/npm/issues/18712

Ten problem jest najpoważniejszy, gdy programiści używają różnych systemów operacyjnych.

EDYCJA: nazwa „lock” jest trudna, jej NPM próbuje dogonić Yarn. To nie jest zablokowany plik. package.jsonjest plikiem ustalonym przez użytkownika, który po zainstalowaniu wygeneruje drzewo folderów node_modules, a następnie zostanie zapisane package-lock.json. Widzisz, jest na odwrót - wersje zależności będą pobierane package.jsonjak zawsze i package-lock.jsonpowinny być wywoływanepackage-tree.json

(mam nadzieję, że to wyjaśniło moją odpowiedź po tylu opiniach)

Uproszczona odpowiedź: zachowaj package.jsonswoje zależności jak zwykle, podczas gdy package-lock.jsonjest to „dokładne i, co ważniejsze, odtwarzalne drzewo modułów_węzła” (zaczerpnięte z samej dokumentacji npm ).

Co do podstępnej nazwy, jej NPM próbuje dogonić Yarn.