Dlaczego "npm install" przepisuje blokadę pakietu.json?

Odkryłem, że będzie nowa wersja npm 5.7.1 z nowym poleceniem npm ci, które zainstaluje się tylko z package-lock.json

Nowe polecenie npm ci instaluje się tylko z pliku blokady. Jeśli Twoja paczka.json i Twój plik blokady są zsynchronizowane, a następnie zgłosi błąd.

Działa poprzez wyrzucenie node_modules i odtworzenie go od zera.

Poza gwarancją, że dostaniesz tylko to, co jest w Twoim pliku blokady, jest to również znacznie szybsze (2x-10x!) niż npm zainstalować, gdy nie zaczyna się z node_modules.

Jak można wziąć od nazwy, oczekujemy, że będzie to wielki Dobrodziej dla środowisk ciągłej integracji. Spodziewamy się również, że osoby, które wykonują wdrożenia produkcyjne z tagów git, zauważą duże zyski.

Użyj nowo wprowadzonego

npm ci

Npm ci obiecuje największe korzyści dla dużych zespołów. Dając programistom możliwość "podpisania" blokady pakietów promuje bardziej efektywną współpracę między dużymi zespołami, a możliwość zainstalowania dokładnie tego, co znajduje się w pliku blokady, może zaoszczędzić dziesiątki, jeśli nie setki godzin deweloperów miesięcznie, uwalniając Zespoły do spędzania więcej czasu na budowaniu i wysyłaniu niesamowitych rzeczy.

Przedstawiamy npm ci dla szybszego i bardziej niezawodnego buduje

Krótka Odpowiedź:

• npm install honors package-lock.json tylko wtedy, gdy spełnia wymagania pakietu.json.
• Jeśli nie spełnia tych wymagań, pakiety są aktualizowane i blokada pakietów jest nadpisywana.
• Jeśli chcesz, aby instalacja nie powiodła się, zamiast nadpisywać package-lock, użyj npm ci.

Oto scenariusz, który może wyjaśnić rzeczy (zweryfikowane z NPM 6.3.0)

Deklarujesz zależność w pakiecie.JSON like:

"depA": "^1.0.0"

Potem robisz, {[5] } co wygeneruje blokadę pakietów.JSON z:

"depA": "1.0.0"

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 aktualizujesz pakiet.json do:

"depA": "^1.1.0"

Następnie powtórz:

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 polecenia npm ci zamiast npm install.

"ci" oznacza "ciągłą integrację".

Zainstaluje zależności projektu oparte na package-lock.plik json zamiast pakietu pobłażliwego.zależności plików json.

Będzie produkować identyczne buildy do Twoich kolegów z drużyny, a także jest znacznie szybszy.

Możesz przeczytać więcej na ten temat w tym wpisie 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ć znacznika --from-lock-file (lub podobnego), aby zainstalować Tylko z package-lock.json bez modyfikowania go.

Będzie to przydatne dla CI, itp. środowiska, w których ważne są powtarzalne budowle.

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

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

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

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

Update

Faktycznie poprawione w 5.6.0. W wersji 5.4.2 pojawił się błąd międzyplatformowy, który powodował, że problem nadal występował.

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

Update 2

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

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

Prawdopodobnie masz coś w stylu:

"typescript":"~2.1.6"

W Twoim package.json który npm aktualizuje do najnowszej wersji minor, w Twoim przypadku jest 2.4.1

Edit: pytanie z OP

Ale to nie wyjaśnia dlaczego "npm install" zmieniłby plik blokady. Czy plik blokady nie jest przeznaczony do tworzenia powtarzalnej kompilacji? Jeśli tak, niezależnie od wartości semver, powinien nadal używać tego samego 2.1.6 wersja.

Odpowiedź:

To ma na celu zablokowanie twoje drzewo zależności. Powiedzmy, że typescript v2.4.1 wymaga widget ~v1.0.0. Po zainstalowaniu npm chwyty widget v1.0.0. Później twój kolega programista (lub ci build) czy npm instaluje i dostaje typescript v2.4.1 ale widget został zaktualizowano do widget v1.0.1. Teraz twój moduł węzła nie jest zsynchronizowany. To jest tym, co package-lock.json zapobiega.

Lub bardziej ogólnie:

Jako przykład rozważ

Pakiet A:

{ "Nazwa": "A", "wersja": "0.1.0", " zależności": { "B": "

Pakiet B:

{"Nazwa": "B", "Wersja": "0.0.1", " zależności": { "C": "

I pakiet C:

{"nazwa": "C", "Wersja": "0.0.1"}

Jeśli są to jedyne wersje A, B I C dostępne w rejestrze, a następnie normalny npm zainstalować zainstaluje:

[email protected] -- [email protected] -- [email protected]

Jednakże, jeśli [email protected] jest publikowany, a następnie świeży npm install a zainstaluje:

[email protected] -- [email protected] -- [email protected] zakładając, że nowa wersja nie zmodyfikowała zależności B. Oczywiście nowa wersja B może zawierać nową wersja C i dowolna liczba nowych zależności. Jeśli takie zmiany są niepożądane, autor może określić zależność od [email protected]. Jeśli jednak autor A i autor B nie są tą samą osobą, to nie ma mowy, aby autor a powiedział, że nie chce wciągać nowe wersje C, gdy B w ogóle się nie zmieniło.

OP Pytanie 2: więc pozwól mi zobaczyć, czy dobrze rozumiem. What you ' re mówi się, że plik lock Określa wersje drugorzędnego zależności, ale nadal opiera się na rozmytym dopasowaniu pakietu.json aby określić zależności najwyższego poziomu. Czy to prawda?

Odpowiedź: Nie. package-lock blokuje całe drzewo pakietów, w tym Pakiety root opisane w package.json. If typescript is locked at 2.4.1 in Twoje package-lock.json, powinno tak pozostać, dopóki nie będzie zmieniony. I powiedzmy, że jutro typescript wyda wersję 2.4.2. Jeśli sprawdzę Twój oddział i uruchomię npm install, npm uszanuje lockfile I install 2.4.1.

Więcej na package-lock.json:

Package-lock.json jest automatycznie generowany dla wszelkich operacji, w których npm modyfikuje drzewo node_modules lub pakiet.json. Opisuje dokładne drzewo, które zostało wygenerowane, tak aby kolejne instalacje były w stanie wygenerować identyczne drzewa, niezależnie od pośrednich aktualizacji zależności.

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

Zapewnienie użytkownikom możliwości "podróży w czasie" do poprzednich stanów node_modules bez konieczności zatwierdzania katalogu siebie.

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

I zoptymalizować 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 pakietu.

Zgodnie z oficjalną dokumentacją, zarówno npm install jak i npm ci instalują zależności potrzebne do projektu.

Główna różnica polega na tym, że npm install instaluje Pakiety biorąc packge.json jako odniesienie. Gdzie w przypadku npm ci, instaluje Pakiety biorąc package-lock.json jako odniesienie, upewniając się za każdym razem pakiet exact jest zainstalowany.

Na ich stronie github jest otwarty problem: https://github.com/npm/npm/issues/18712

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

EDIT: nazwa "lock" jest trudna, jej NPM próbuje dogonić Yarn. To nie jest zamknięty plik. package.json jest plikiem ustalonym przez użytkownika, który po "zainstalowaniu" wygeneruje drzewo katalogów node_modules, które następnie zostanie zapisane w package-lock.json. Więc widzisz, to odwrotnie - wersje zależności będą pobierane z package.json jak zawsze, a package-lock.json powinny być nazwane package-tree.json

(mam nadzieję, że to sprawiło, że moja odpowiedź stała się jaśniejsza, po tylu downvotach)

Uproszczona odpowiedź: package.json należy mieć swoje zależności jak zwykle, podczas gdy package-lock.json jest "dokładnym i co ważniejsze powtarzalnym drzewem node_modules" (zaczerpniętym z npm docs ).