Jaka jest różnica między npm-shrinkwrap.json i package-lock.json?

158

Wraz z wydaniem npm @ 5 , będzie teraz pisać, package-lock.jsonchyba że npm-shrinkwrap.jsonjuż istnieje.

Zainstalowałem npm @ 5 globalnie przez:

npm install npm@5 -g

A teraz, jeśli npm-shrinkwrap.jsonzostanie znaleziony podczas:

npm install

zostanie wydrukowane ostrzeżenie:

npm WARN read-shrinkwrap This version of npm
is compatible with lockfileVersion@1,
but npm-shrinkwrap.json was generated for lockfileVersion@0.
I'll try to do my best with it!

Więc moim wnioskiem jest to, że powinienem wymienić folię na plik package-lock.json.

Ale dlaczego istnieje nowy format? Co może package-lock.jsonzrobić, czego npm-shrinkwrap.jsonnie mogą?

npm npm-shrinkwrap package-lock.json k0pernikus
źródło

Odpowiedzi:

176

Pliki mają dokładnie taką samą zawartość, ale istnieje kilka różnic w sposobie ich obsługi przez npm, opisanych w witrynie docs, a także w pliku docs w repozytorium npm, który zaczyna się od wyraźnego wyjaśnienia różnicy między tymi dwoma plikami :

package-lock.jsonnigdy nie jest publikowany w npm, natomiast npm-shrinkwrapjest domyślnie
package-lock.json pliki, które nie znajdują się w pakiecie najwyższego poziomu, są ignorowane, ale pliki powłoki należące do zależności są respektowane
npm-shrinkwrap.jsonjest wstecznie kompatybilny z wersjami npm 2, 3 i 4, natomiast package-lock.jsonjest rozpoznawany tylko przez npm 5+

Możesz przekonwertować istniejący package-lock.jsonna plik npm-shrinkwrap.json, uruchamiając npm shrinkwrap.

A zatem:

Jeśli nie publikujesz pakietu w npm, wybór pomiędzy tymi dwoma plikami nie ma większego znaczenia. Możesz chcieć użyć, package-lock.jsonponieważ jest to ustawienie domyślne, a jego nazwa jest bardziej zrozumiała dla początkujących npm; alternatywnie, możesz chcieć użyć npm-shrinkwrap.jsondo wstecznej kompatybilności z npm 2-4, jeśli trudno ci upewnić się, że wszyscy w twoim zespole programistów korzystają z npm 5+. (Zwróć uwagę, że npm 5 został wydany 25 maja 2017 roku; kompatybilność wsteczna będzie coraz mniej ważna, im dalej będziemy od tej daty, ponieważ większość ludzi w końcu dokona aktualizacji.)
Jeśli są publikując swój pakiet do KMP, masz wybór pomiędzy:
1. używając a, package-lock.jsonaby dokładnie zarejestrować, które wersje zależności zainstalowałeś, ale pozwalając osobom instalującym Twój pakiet na użycie dowolnej wersji zależności, która jest zgodna z zakresami wersji narzuconymi przez Ciebie package.json, lub
2. użycie znaku, npm-shrinkwrap.jsonaby zagwarantować, że każdy, kto zainstaluje Twój pakiet, otrzyma dokładnie tę samą wersję wszystkich zależności
Oficjalny pogląd opisany (bardzo zwięźle) w dokumentach jest taki, że opcja 1 powinna być używana dla bibliotek (prawdopodobnie w celu zmniejszenia liczby duplikatów pakietów spowodowanych, gdy wiele zależności pakietu zależy od nieco różnych wersji tej samej zależności wtórnej) , ale ta opcja 2 może być rozsądna w przypadku plików wykonywalnych, które mają zostać zainstalowane globalnie.

Mark Amery
źródło

+1 - czy możesz jednak wyjaśnić swój drugi punkt? Jaka jest różnica między tym zachowaniem a posiadaniem powłoki npm-shrinkwrap?

Rhys,

@Rhys druga kula nie ma znaczenia w praktyce, chyba że robisz coś dziwnego. Zasadniczo, to po prostu mówi, że jeśli biblioteka jakoś nie opublikować package-lock.json(co nie jest możliwe), a następnie, jeśli były do zainstalowania tej biblioteki jako zależność jakiegoś innego pakietu, że biblioteki package-lock.jsonbędą ignorowane przez KMP. Jeśli jednak biblioteka publikuje npm-shrinkwrap.jsoni instalujesz bibliotekę jako zależność, wówczas jako dodatkowe zależności zainstalujesz również dokładne wersje wszystkich zależności określonych w bibliotece npm-shrinkwrap.json.

Mark Amery,

Czy możesz dodać, że npm ciistnieje, aby zapewnić instalację package-lock.jsonjako tylko do odczytu. ( npm installmutuje package-lock.jsonpowodujące zamieszanie i potencjalne błędy i nie wykorzystuje tego samego package-lock.json)

k0pernikus

@ k0pernikus Myślę, że nie ma żadnej różnicy między tym, jak npm ciuchwyty npm-shrinkwrap.jsoni package-lock.json- jakie ma to znaczenie w przypadku tego pytania o różnicę między dwoma plikami? Ponadto po przeczytaniu dookoła: myślę, że „ npm install... nie korzysta z package-lock.json” było fałszywe od npm 5.4 - myślę, że npm installteraz szanuje twoje, package-lock chyba że jest całkowicie niezgodne z twoim package.json, w takim przypadku to drugie będzie miało pierwszeństwo. (Ale przez jakiś czas byłem poza światem JavaScript - czy coś mi brakuje?)

Mark Amery

Wyjaśnienie od programisty NPM :

Pomysł jest taki, aby pakiet-lock.json był najnowszym i najlepszym w technologii shrinkwrap, a npm-shrinkwrap.json zarezerwowanym dla tych kilku cennych ludzi, którzy bardzo dbają o to, aby ich biblioteki miały dokładne moduły node_modules - i dla osób, które chcą, aby CI używające npm @> = 2 instalowało określone drzewo bez konieczności modyfikowania jego wersji npm.

Nowy plik blokujący („package-lock.json”) ma w zasadzie cały ten sam kod, dokładnie taki sam format jak npm-shrinkwrap (możesz zmieniać ich nazwy między sobą!). Wydaje się, że jest to również coś, co społeczność zdaje się rozumieć: „ma plik blokujący” wydaje się klikać znacznie szybciej w przypadku ludzi. Wreszcie posiadanie nowego pliku oznaczało, że mogliśmy mieć względnie niskie ryzyko wstecznej kompatybilności z powłoką shrinkwrap bez konieczności robienia dziwnych rzeczy, takich jak zezwolenie na publikację, o którym mowa w poście nadrzędnym.

Poważny M.
źródło

Nadal nie rozumiem różnicy. Jeśli npm-shrinkwrapdotyczy dokładnych modułów node_modules .... Zakładam, że package-lock.jsonblokowanie jest mniejsze niż dokładne? A jeśli tak, to co nie blokuje, a co npm-shrinkwrapblokuje?

dman,

źle zrozumiałeś @dman. pakiet-lock to nowa wersja npm-shrinkwrap. package-lock to opt-out (więc musisz usunąć tę funkcję, ponieważ jest domyślnie włączona), npm-shrinkwrap jest opt-in (więc musisz ją włączyć, ponieważ nie jest dołączona do mojego domyślnego). powodem, dla którego wprowadzili blokadę pakietu jest to, że 1. użytkownik ma teraz bardziej oszczędny sposób radzenia sobie z zależnościami, ponieważ jest on domyślnie włączony, a 2. nazwa wskazuje na to, co jest przeciwieństwem „powłoki”. npm-shrinkwrap miał pewne specjalne ustawienia zachowania zależności, których nie ma teraz blokada pakietu. npm-shrinkwrap jest teraz przestarzały.

SeriousM

to jest niepoprawne. Mówiąc, że pakiet-lock jest nową wersją npm-shrinkwrap, mówisz, że jest to zamiennik. npm-shrinkwrap nie jest przestarzały i ma różnice w stosunku do package-lock.json. Ponadto pakiet package-lock.json ma błąd, podczas gdy npm-shrinkwrap nie ... w ten sposób kładzie większy nacisk, aby nie były tym samym kodem.

dman

Również pakiet-lock.json jest nachalny. Więc może łatwo powodować konflikty scm, jeśli wywołasz "npm i", podczas gdy powłoka powinna być jawnie wygenerowana i nie spowoduje konfliktów na serwerach ci. Tak, mogę się mylić.

norekhov

@dman "package-lock.json ma błąd, podczas gdy npm-shrinkwrap nie" - nie, nie. Nic nie wskazuje na to w problemie, z którym łączysz się; nawet o tym nie wspomina npm-shrinkwrap. Jak zauważyłem w mojej odpowiedzi, konwersja a package-lock.jsondo an npm-shrinkwrap.jsonjest dosłownie wykonywana poprzez zmianę nazwy pliku; oni są „ten sam kod”.

Mark Amery,

Myślę, że chodziło o to, aby - zapisywanie i powłoka były wykonywane domyślnie, ale unikały potencjalnych problemów z powłoką, która miałaby miejsce tam, gdzie nie byłaby potrzebna. Więc po prostu nadali mu nową nazwę pliku, aby uniknąć konfliktów. Ktoś z npm wyjaśnił to dokładniej tutaj:

https://www.reddit.com/r/javascript/comments/6dgnnq/npm_v500_released_save_by_default_lockfile_better/di3mjuk/

Odpowiednia wycena:

npm domyślnie publikuje większość plików w katalogu źródłowym, a ludzie publikują okładki od lat. Nie chcieliśmy zrywać kompatybilności. Z domyślnymi opcjami --save i shrinkwrap, istniało duże ryzyko, że przypadkowo dostanie się do rejestru i rozprzestrzeni się przez niego, a nasza zdolność do aktualizowania deps i dedupe ... null.

Więc wybraliśmy nową nazwę. I nagle wybraliśmy nową nazwę. Nowy plik blokujący ma w zasadzie cały ten sam kod, dokładnie ten sam format

Cody Brumfield
źródło