npm 5 został wydany dzisiaj, a jedną z nowych funkcji są deterministyczne instalacje wraz z tworzeniem package-lock.json
pliku.
Czy ten plik powinien być pod kontrolą źródła?
Zakładam, że jest podobny yarn.lock
i composer.lock
oba powinny być pod kontrolą źródła.
git log
obsługę.Odpowiedzi:
Tak,
package-lock.json
jest 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 znpm help package-lock.json
:źródło
package-lock.json
do mojego.gitignore
... powodowało to o wiele więcej problemów niż ich rozwiązywanie. Zawsze powoduje konflikt, gdy łączymy lub zmieniamy bazę, a gdy scalanie powodujepackage-lock.json
uszkodzenie na serwerze CI, to jest ból, że trzeba go nadal naprawiać.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.
źródło
package-lock.json
pliku podczas pracy w systemie SCM z pniami i rozgałęzieniami? Wprowadzam pewne zmiany w gałęzi, które muszą zostać scalone do pnia ... czy teraz muszę (jakoś) rozwiązać konflikty między dwomapackage-lock.json
plikami? To jest bolesne.Tak, powinieneś:
package-lock.json
.npm ci
zamiastnpm install
podczas budowania aplikacji zarówno na CI, jak i na lokalnym komputerze programistycznymPrzepływ
npm ci
pracy wymaga istnienia plikupackage-lock.json
.Dużym minusem
npm install
polecenia jest jego nieoczekiwane zachowanie, które może mutowaćpackage-lock.json
, podczas gdynpm ci
używa tylko wersji określonych w pliku blokującym i powoduje błądpackage-lock.json
i niepackage.json
są zsynchronizowanepackage-lock.json
brakuje a.Dlatego działając
npm install
lokalnie, szczególnie. w większych zespołach z wieloma programistami może prowadzić do wielu konfliktów wewnątrzpackage-lock.json
i deweloperów, aby zdecydować się na całkowite ich usunięciepackage-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.json
dostaniesz 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 albonpm update {dependency}
albonpm 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 :
I w odniesieniu do różnicy między
npm ci
vsnpm install
:Uwaga: podałem podobną odpowiedź tutaj
źródło
whose build would fail one day because a random dependency got a breaking update
jakimś problemem. Choć pozostawia możliwość uzależnienia dziecka od tego samego problemu.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.2.3
w swoimpackage.json
, ale jak możesz upewnić się, że za każdym razemnpm install
wybierzesz tę samą wersję na maszynie deweloperskiej i serwerze kompilacji, szczególnie te pakiety zależności pośrednich? Cóż,package-lock.json
zapewni. (Za pomocąnpm ci
którego instaluje pakiety oparte na pliku blokady)npm audit fix
(myślę, że funkcja kontroli pochodzi z npm wersji 6).źródło
npm ci
. Ludzie często wspominają, żepackage-lock.json
pozwala na deterministyczną instalację pakietów, ale prawie nigdy nie wspominają o komendzie, która ułatwia to zachowanie! Wiele osób prawdopodobnie błędnie zakłada, żenpm install
instaluje dokładnie to, co jest w pliku blokady ...npm ci
. Twój zespół / główny programista może zdecydować, kiedy zaktualizować. Jeśli wszyscy po prostu arbitralnie to popełniają, nie ma sensu, a to po prostu powoduje hałas w twoim repozytorium. Dokumentacja NPM powinna to wyjaśnić. Myślę, że większość programistów jest po prostu zdezorientowana tą funkcją.Nie zatwierdzam tego pliku w moich projektach. Jaki jest sens ?
Chociaż prawdą jest, że nigdy nie używam ^ w pakiecie.json do bibliotek, ponieważ miałem z tym złe doświadczenia.
źródło
package-lock.json
. Niektóre repozytoria mogą nie wymagać korzyści, które z tego wynikają, i wolą nie mieć automatycznie generowanej treści w źródle.Do ludzi narzekających na hałas podczas wykonywania git diff:
Użyłem aliasu:
Aby zignorować pakiet-lock.json w plikach diff dla całego repozytorium (wszyscy go używający), możesz dodać to do
.gitattributes
: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.
źródło
gd() { git diff --color-words $1 $2 -- :!/yarn.lock :!/package-lock.json; }
w moim .bashrc zamiast aliasu.Tak, możesz zatwierdzić ten plik. Z oficjalnych dokumentów npm :
źródło
npm ci
aby zainstalować z pliku package-lock.jsonWyłącz pakiet-lock.json globalnie
wpisz w swoim terminalu:
to naprawdę działa dla mnie jak magia
źródło
~/.npmrc
(przynajmniej na moich makach) z zawartościąpackage-lock=false
i to samo można zrobić w każdym konkretnym projekcie oboknode_modules/
(np.echo 'package-lock=false' >> .npmrc
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: -
Cons:-
Edycja: - instalacja npm nie upewni się, że wszyscy w projekcie są w tej samej wersji pakietu. npm ci ci w tym pomoże.
źródło
npm ci
zamiastnpm install
.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 install
uruchomieniu 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:
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
źródło