Czy mogę zatwierdzić plik package-lock.json utworzony przez npm 5?

npm 5 został wydany dzisiaj, a jedną z nowych funkcji są deterministyczne instalacje wraz z tworzeniem package-lock.jsonpliku.

Czy ten plik powinien być pod kontrolą źródła?

Zakładam, że jest podobny yarn.locki composer.lockoba powinny być pod kontrolą źródła.

Tak, package-lock.jsonjest przeznaczony do kontroli źródła. Jeśli używasz npm 5, możesz zobaczyć to w wierszu poleceń: created a lockfile as package-lock.json. You should commit this file.Zgodnie z npm help package-lock.json:

package-lock.jsonjest generowany automatycznie dla wszystkich operacji, w których npm modyfikuje albo node_modulesdrzewo, albo package.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 node_modulesbez 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.

Jednym z kluczowych szczegółów package-lock.jsonjest to, że nie można go opublikować i zostanie zignorowany, jeśli zostanie znaleziony w innym miejscu niż pakiet najwyższego poziomu. Dzieli format z npm-shrinkwrap.json (5), który jest zasadniczo tym samym plikiem, ale umożliwia publikację. Nie jest to zalecane, chyba że wdrażasz narzędzie CLI lub w inny sposób używasz procesu publikacji do produkcji pakietów produkcyjnych.

Jeśli oba package-lock.jsoni npm-shrinkwrap.jsonsą obecne w głównym pakietu, package-lock.jsonbędą całkowicie ignorowane.

Tak, jest przeznaczony do zameldowania. Chcę zasugerować, że otrzyma swoje własne unikalne zatwierdzenie. Stwierdzamy, że powoduje to duży hałas w naszych różnicach.

Tak, powinieneś:

1. popełnić package-lock.json.
2. używaj npm cizamiastnpm install podczas budowania aplikacji zarówno na CI, jak i na lokalnym komputerze programistycznym

Przepływ npm cipracy wymaga istnienia pliku package-lock.json.

Dużym minusem npm installpolecenia jest jego nieoczekiwane zachowanie, które może mutować package-lock.json, podczas gdy npm ciużywa tylko wersji określonych w pliku blokującym i powoduje błąd

• jeśli package-lock.jsoni nie package.jsonsą zsynchronizowane
• jeśli package-lock.jsonbrakuje a.

Dlatego działając npm installlokalnie, szczególnie. w większych zespołach z wieloma programistami może prowadzić do wielu konfliktów wewnątrz package-lock.jsoni deweloperów, aby zdecydować się na całkowite ich usunięcie package-lock.json.

Istnieje jednak mocny przypadek, że można ufać, że zależności projektu są rozwiązywane powtarzalnie w niezawodny sposób na różnych komputerach.

Od A package-lock.jsondostaniesz dokładnie to: stan znany na rynek pracy.

W przeszłości miałem projekty bez plików package-lock.json/ npm-shrinkwrap.json/ yarn.lock, których kompilacja by się nie udała pewnego dnia, ponieważ losowa zależność otrzymała przełomową aktualizację.

Te problemy są trudne do rozwiązania, ponieważ czasami trzeba odgadnąć, jaka była ostatnia działająca wersja.

Jeśli chcesz dodać nową zależność, nadal działa npm install {dependency}. Jeśli chcesz zaktualizować, użyj albo npm update {dependency}albo npm install ${dependendency}@{version}i zatwierdź zmienioną package-lock.json.

Jeśli aktualizacja się nie powiedzie, możesz powrócić do ostatniego znanego działania package-lock.json.

Aby zacytować npm doc :

Zdecydowanie zaleca się, aby wygenerowaną blokadę pakietu przypisać do kontroli źródła: pozwoli to każdemu innemu zespołowi, Waszym wdrożeniom, CI / ciągłej integracji oraz każdemu innemu, kto uruchomi npm instalację w twoim źródle pakietów, aby uzyskać dokładnie to samo drzewo zależności nad którym pracowałeś. Dodatkowo różnice od tych zmian są czytelne dla człowieka i poinformują cię o wszelkich zmianach dokonanych przez npm w twoim module_węzła, dzięki czemu możesz zauważyć, czy jakieś zależności przechodnie zostały zaktualizowane, podniesione itp.

I w odniesieniu do różnicy między npm civsnpm install :

• Projekt musi mieć istniejący pakiet-lock.json lub npm-shrinkwrap.json.
• Jeśli zależności w blokadzie pakietu nie pasują do zależności w pakiecie.json, npm cizakończy działanie z błędem, zamiast aktualizować blokadę pakietu.
• npm ci można instalować tylko całe projekty na raz: za pomocą tego polecenia nie można dodawać indywidualnych zależności.
• Jeśli a node_modulesjest już obecny, zostanie automatycznie usunięty przed npm cirozpoczęciem instalacji.
• Nigdy nie napisze do package.jsonżadnej z blokad pakietów: instalacje są zasadniczo zawieszone.

Uwaga: podałem podobną odpowiedź tutaj

Tak, najlepszą praktyką jest zameldowanie (TAK, ZAMELDOWANIE)

Zgadzam się, że spowoduje to dużo hałasu lub konfliktu, gdy zobaczysz różnicę. Ale korzyści to:

1. gwarantuje dokładnie taką samą wersję każdego pakietu . Ta część jest najważniejsza przy budowaniu w różnych środowiskach w różnych momentach. Możesz używać ^1.2.3w swoim package.json, ale jak możesz upewnić się, że za każdym razem npm installwybierzesz tę samą wersję na maszynie deweloperskiej i serwerze kompilacji, szczególnie te pakiety zależności pośrednich? Cóż, package-lock.jsonzapewni. (Za pomocą npm ciktórego instaluje pakiety oparte na pliku blokady)
2. usprawnia proces instalacji.
3. pomaga w nowej funkcji kontroli npm audit fix(myślę, że funkcja kontroli pochodzi z npm wersji 6).

Nie zatwierdzam tego pliku w moich projektach. Jaki jest sens ?

1. To jest generowane
2. Jest to przyczyną błędu integralności kodu SHA1 w gitlab z kompilacjami gitlab-ci.yml

Chociaż prawdą jest, że nigdy nie używam ^ w pakiecie.json do bibliotek, ponieważ miałem z tym złe doświadczenia.

Do ludzi narzekających na hałas podczas wykonywania git diff:

git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

Użyłem aliasu:

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

Aby zignorować pakiet-lock.json w plikach diff dla całego repozytorium (wszyscy go używający), możesz dodać to do .gitattributes:

package-lock.json binary
yarn.lock binary

Spowoduje to różnice, które pokazują „Pliki binarne a / package-lock.json i b / package-lock.json różnią się przy każdej zmianie pliku blokady pakietu. Dodatkowo niektóre usługi Git (zwłaszcza GitLab, ale nie GitHub) również wykluczą te pliki (nie zmieniły się już 10 000 wierszy!) z różnic podczas przeglądania online.

Tak, możesz zatwierdzić ten plik. Z oficjalnych dokumentów npm :

package-lock.jsonjest generowany automatycznie dla wszystkich operacji, w których npmmodyfikuje się node_modulesdrzewo lub package.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 [.]

Wyłącz pakiet-lock.json globalnie

wpisz w swoim terminalu:

npm config set package-lock false

to naprawdę działa dla mnie jak magia

Tak, standardową praktyką jest popełnienie pliku package-lock.json

Głównym powodem popełnienia pliku package-lock.json jest to, że wszyscy w projekcie korzystają z tej samej wersji pakietu.

Plusy: -

• Jeśli przestrzegasz ścisłej wersji i nie pozwalasz na automatyczną aktualizację do głównych wersji, aby uchronić się przed niezgodnymi wstecznymi zmianami w pakietach innych firm, popełnienie blokady pakietu bardzo pomaga.
• Jeśli zaktualizujesz konkretny pakiet, zostanie on zaktualizowany w pliku package-lock.json, a wszyscy korzystający z repozytorium zostaną zaktualizowani do tej konkretnej wersji, gdy przyjmą zmiany.

Cons:-

• Może sprawić, że twoje żądania ściągnięcia będą wyglądać brzydko :)

Edycja: - instalacja npm nie upewni się, że wszyscy w projekcie są w tej samej wersji pakietu. npm ci ci w tym pomoże.

Używam npm do generowania zminimalizowanego / uglifikowanego css / js i wygenerowania javascript potrzebnego na stronach obsługiwanych przez aplikację django. W moich aplikacjach Javascript działa na stronie, aby tworzyć animacje, czasami wykonuję wywołania ajax, pracuję w ramach VUE i / lub współpracuję z css. Jeśli pakiet-lock.json ma pewną nadrzędną kontrolę nad tym, co znajduje się w pakiecie.json, może być konieczne, aby istniała jedna wersja tego pliku. Z mojego doświadczenia wynika, że ​​albo nie wpływa to na to, co jest instalowane przez npm install, albo jeśli tak, to nie wpłynęło to negatywnie na aplikacje, które wdrażam według mojej wiedzy. Nie używam mongodb ani innych takich aplikacji, które są tradycyjnie cienkimi klientami.

Usuwam pakiet-lock.json z repozytorium, ponieważ instalacja npm generuje ten plik, a instalacja npm jest częścią procesu wdrażania na każdym serwerze, na którym działa aplikacja. Kontrola wersji węzła i npm odbywa się ręcznie na każdym serwerze, ale uważam, że są takie same.

Po npm installuruchomieniu na serwerze zmienia pakiet-lock.json, a jeśli wystąpią zmiany w pliku, który jest rejestrowany przez repozytorium na serwerze, następne wdrożenie WONT pozwala wyciągnąć nowe zmiany z początku. Oznacza to, że nie można wdrożyć, ponieważ ściągnięcie zastąpi zmiany wprowadzone w pliku package-lock.json.

Nie można nawet zastąpić lokalnie generowanego pliku package-lock.json tym, co znajduje się w repozytorium (zresetować główny wzorzec dysku twardego), ponieważ npm będzie narzekać, gdy wyda polecenie, jeśli pakiet-lock.json nie odzwierciedla tego, co jest w repozytorium node_modules z powodu instalacji npm, tym samym przerywając wdrożenie. Teraz, jeśli to wskazuje, że w module node_modules zostały zainstalowane nieco inne wersje, to nigdy nie sprawiło mi to problemów.

Jeśli node_modules nie znajduje się na twoim repozytorium (i nie powinno tak być), pakiet-lock.json powinien zostać zignorowany.

Jeśli czegoś brakuje, proszę o poprawienie mnie w komentarzach, ale punkt, w którym wersjonowanie pochodzi z tego pliku, nie ma sensu. Plik package.json zawiera numery wersji i zakładam, że ten plik służy do budowania pakietów, gdy nastąpi instalacja npm, ponieważ kiedy go usuwam, instalacja npm narzeka w następujący sposób:

jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

kompilacja kończy się niepowodzeniem, jednak podczas instalowania modułów node_modules lub stosowania npm do kompilacji js / css nie zgłoszę żadnych skarg, jeśli usunę pakiet package-lock.json

jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...