Czy powinienem zatwierdzić plik yarn.lock i do czego służy?

304

Przędza tworzy yarn.lockplik po wykonaniu yarn install.

Czy należy to przypisać do repozytorium, czy zignorować? Po co to jest?

yarnpkg

— rlay3
źródło

3

IMHO, to pytanie (i większość poniższych odpowiedzi) jest niekompletne z powodu braku pytania „Jak i kiedy powinniśmy zregenerować plik yarn.lock?”

— MarkHu

1

Czy wiesz teraz jak i kiedy?

— jayarjo

@MarkHu znalazł to tutaj: yarnpkg.com/lang/en/docs/yarn-lock/#toc-managed-by-yarn Tak w zasadzie:

Your yarn.lock file is auto-generated and should be handled entirely by Yarn. As you add/upgrade/remove dependencies with the Yarn CLI, it will automatically update your yarn.lock file.

— jayarjo

Powiązane: stackoverflow.com/questions/45614973/...

— k0pernikus

271

Tak, powinieneś to sprawdzić, patrz Migracja z npm

Yarn wygeneruje plik yarn.lock w katalogu głównym pakietu. Nie musisz czytać ani rozumieć tego pliku - po prostu zaznacz go w celu kontroli źródła.

— ckuijjer
źródło

33

Niezłe znalezisko. Znalazłem następujące z ich dokumentów, które odpowiadają „po co to jest?”: „Klient npm instaluje zależności w katalogu node_modules w sposób nieokreślony. Oznacza to, że w oparciu o zależności kolejności są instalowane, struktura modułów node_modules katalog może być różny dla różnych osób. Różnice te mogą powodować błędy „działające na moim komputerze”, których wyłapanie zajmuje dużo czasu ”.

— rlay3

13

Ciąg dalszy: „Przędza rozwiązuje te problemy związane z wersjonowaniem i niedeterminizmem za pomocą plików blokujących i algorytmu instalacyjnego, który jest deterministyczny i niezawodny. Te pliki blokujące blokują zainstalowane zależności do określonej wersji i zapewniają, że każda instalacja powoduje dokładnie taką samą strukturę plików w node_modules na wszystkich komputerach. ”

— rlay3

Zamiast powiedzieć „nie znaleziono pliku blokującego”. Powinien po prostu powiedzieć „Generowanie pliku yarn.lock”. Duh :) To nie jest błąd, ale ten pierwszy brzmi jak błąd. Ten drugi będzie wystarczająco alarmujący dla każdego w odwrotnym scenariuszu (w którym spodziewają się mieć plik yarn.lock, ale najwyraźniej nie).

— Alexander Mills,

7

Doceniam, że yarn.lock blokuje nasz projekt do konkretnych wersji pakietów, ale wydaje mi się, że użycie słowa „lock” jest niefortunne. Zwykle pliki blokowania (takie jak .ldb ) są sposobem na ograniczenie zasobu do jednego procesu na raz, aby zapobiec uszkodzeniom powodującym aktualizacje. Takie pliki blokujące zdecydowanie nie powinny być poddawane kontroli wersji, co prawdopodobnie wynika z większości nieporozumień związanych z plikiem yarn.lock.

— Antony

2

Naprawdę nie podoba mi się zdanie „nie musisz czytać ani rozumieć tego pliku”. To ważny plik do utrzymania projektu.

— Nathan Goings,

83

Zależy od tego, jaki jest twój projekt:

Czy twój projekt jest aplikacją? Następnie: tak
Czy twój projekt to biblioteka? Jeśli tak: Nie

Bardziej szczegółowy opis tego można znaleźć w tym numerze GitHub, w którym jeden z twórców Yarn np. mówi:

Pakiet.json opisuje zamierzone wersje pożądane przez oryginalnego autora, a yarn.lock opisuje ostatnią znaną dobrą konfigurację dla danej aplikacji.

yarn.lockZostanie wykorzystany tylko plik projektu najwyższego poziomu. Więc jeśli jeden projekt nie będzie używany jako samodzielny i nie zostanie zainstalowany w innym projekcie, to nie ma yarn.locksensu zatwierdzać żadnego -pliku - zamiast tego zawsze będzie package.jsonzależało od -pliku, aby przekazać, jakich wersji zależności oczekuje wtedy projekt.

— VoxPelli
źródło

7

Z drugiej strony, czy posiadanie pliku blokady w projektach bibliotecznych nie wpłynęłoby na odtwarzalność ich odpowiednich testów?

— Nazwa E_net4 zmienia się cały czas

1

Jeśli poprawnie przeczytam Twój opis, niż „Czy Twój projekt jest biblioteką?” można odpowiedzieć „Jeśli chcesz”. Wydaje się, że nie ma to wad, ale może być przydatne, jeśli masz skomplikowane devDependencies i chcesz, aby każdy programista twojej biblioteki lib miał taką samą skrypt budowania i testowania. Dobrze?

— Pipo

4

Ponieważ plik blokady nie będzie przestrzegany przez żadnego użytkownika Twojej biblioteki, więc poleganie na nim podczas tworzenia biblioteki może dać fałszywe poczucie bezpieczeństwa

— VoxPelli,

1

Dart ma ten sam system z pubspec.yaml i pubspec.lock i zaleca to samo, co w odpowiedzi. Zobacz to pytanie i tę pozycję dokumentacji.

— Jonas Kello,

16

Zapoznaj się z tym wpisem na oficjalnym blogu Yarn: Pliki blokad powinny być

— zatwierdzane

66

Widzę, że są to dwa oddzielne pytania w jednym. Pozwól, że odpowiem na oba pytania.

Czy powinieneś zatwierdzić plik do repo?

Tak. Jak wspomniano w odpowiedzi ckuijjer, w Przewodniku migracji zaleca się włączenie tego pliku do repozytorium. Czytaj dalej, aby zrozumieć, dlaczego musisz to zrobić.

Co to jest yarn.lock?

Jest to plik, który przechowuje dokładne wersje zależności dla twojego projektu wraz z sumami kontrolnymi dla każdego pakietu. W ten sposób przędza zapewnia spójność zależności.

Aby zrozumieć, dlaczego ten plik jest potrzebny, najpierw musisz zrozumieć, na czym polegał problem z oryginalnymi NPM package.json. Po zainstalowaniu pakietu program NPM zapisze zakres dozwolonych wersji zależności zamiast konkretnej wersji (semver). Program NPM spróbuje pobrać aktualizację najnowszej wersji zależności w określonym zakresie (tj. Nieprzerwane aktualizacje poprawek). Z tym podejściem wiążą się dwa problemy.

Autorzy zależności mogą wydać aktualizacje wersji łatki, wprowadzając przełomową zmianę, która wpłynie na twój projekt.
Dwóch programistów działających npm installw różnych momentach może uzyskać inny zestaw zależności. Co może spowodować, że błąd nie będzie odtwarzalny w dwóch dokładnie takich samych środowiskach. Może to na przykład powodować problemy ze stabilnością kompilacji serwerów CI.

Z drugiej strony przędza przyjmuje maksymalną przewidywalność. Tworzy yarn.lockplik, aby zapisać dokładne wersje zależności. Posiadanie tego pliku w przędzy spowoduje użycie zapisanych wersji yarn.lockzamiast rozwiązywania wersji z package.json. Ta strategia gwarantuje, że nie wystąpi żaden z opisanych powyżej problemów.

yarn.lockjest podobny do npm-shrinkwrap.jsontego, który można utworzyć za pomocą npm shrinkwrappolecenia. Sprawdź tę odpowiedź, wyjaśniając różnice między tymi dwoma plikami.

— Juriy
źródło

1

Ale widzę, yarn.lockże od czasu do czasu jestem aktualizowany, czy wiesz, dlaczego i kiedy to yarnrobi?

— jayarjo

1

Problemy z przędzą # 4379 i # 4147 sugerują, że yarnaktualizacje yarn.lockw wielu przypadkach, w tym uruchamianie yarn installbez zmian w pliku package.json. Używanie yarn install --frozen-lockfilezgodnie z sugestią w Dlaczego uruchamianie przędzy w systemie Windows zmienia yarn.lock (lub konfigurowanie go za pomocą .yarnrc) wydaje się najlepszym wyborem .

— Lauri Harpf,

npm ma obecnie package-lock.jsoni npm ci. Ten przepływ pracy jest analogiczny jak w przypadku przędzy yarn.locki yarn install --frozen-lockfile.

— k0pernikus

10

Sądzę, że tak, ponieważ Yarn tworzy własny plik yarn.lock: https://github.com/yarnpkg/yarn

Służy do deterministycznego rozwiązywania zależności pakietów.

— jarekwg
źródło

8

Powinieneś:

dodaj go do repozytorium i zatwierdź
użyj yarn install --frozen-lockfilei NIE yarn installjako domyślnie zarówno lokalnie, jak i na serwerach kompilacji CI.

(Otworzyłem bilet w narzędziu do śledzenia problemów z przędzą, aby uzasadnić domyślne zachowanie zamrożonego pliku blokującego, patrz # 4147 ).

Uważaj, aby NIE ustawić frozen-lockfileflagi w .yarnrcpliku, ponieważ uniemożliwi to zsynchronizowanie pliku package.json i yarn.lock. Zobacz pokrewny problem z przędzą na github

yarn installmoże nieoczekiwanie mutować twoją przędzę. blokować , powodując, że roszczenia dotyczące powtarzalnych kompilacji są nieważne. Powinieneś używać go tylko yarn installdo inicjalizacji yarn.lock i aktualizacji.

Również esp. w większych zespołach możesz mieć dużo hałasu wokół zmian w blokadzie przędzy tylko dlatego, że programista przygotowywał swój lokalny projekt.

Aby uzyskać więcej informacji, przeczytaj moją odpowiedź na temat pakietu-lock.json npm, ponieważ dotyczy to również tutaj.

Zostało to niedawno wyjaśnione w dokumentacji dotyczącej instalacji przędzy :

yarn install

Zainstaluj wszystkie zależności wymienione w pakiecie.json w lokalnym folderze node_modules.

yarn.lockPlik jest wykorzystywany w sposób następujący:

Jeśli plik yarn.lock jest obecny i wystarcza do spełnienia wszystkich zależności wymienionych w pakiecie.json, zostaną zainstalowane dokładne wersje zapisane w pliku yarn.lock, a yarn.lock pozostanie niezmieniony. Przędza nie będzie sprawdzać nowszych wersji.

Jeśli yarn.lock jest nieobecny lub nie jest wystarczający do spełnienia wszystkich zależności wymienionych w pakiecie.json (na przykład, jeśli ręcznie dodasz zależność do package.json), Yarn szuka najnowszych dostępnych wersji, które spełniają ograniczenia w pakiecie .json. Wyniki są zapisywane w yarn.lock.

Jeśli chcesz się upewnić, że yarn.lock nie jest aktualizowany, użyj --frozen-lockfile.

— k0pernikus
źródło

Chociaż jest to prawda, jedyne, co mogę pomyśleć, że będziesz musiał użyć, --frozen-lockfilejeśli ktoś ręcznie zaktualizuje pakiet.json bez późniejszego uruchamiania yarn installi zatwierdzania aktualizacji. Dlatego CI może chcieć użyć tej flagi, ale programiści nie powinni, ponieważ ukrywa problemy.

— jkrehm

@jkrehm Zależy od tego, co masz na myśli przez ukrywanie problemów. Miałem więcej kłopotów z niespodziewanie zmienionymi yarn.lockplikami wprowadzonymi przez yarn installalbo przez wzdęcie żądań ściągania, albo przez powodowanie niepotrzebnych konfliktów scalania, albo przez ciągnięcie uszkodzonej biblioteki. (Tylko dlatego, że biblioteka używa semvaru, nie oznacza to, że łatka / drobna aktualizacja nie zepsuje twojej aplikacji - byłem tam). Uważam, że aktualizacja yarn.lockpowinna być tylko krokiem ręcznym, dlatego polegam yarn install --frozen-lockfile(i npm cina projektach npm) nawet na mojej maszynie programistycznej, ponieważ jest niezawodna i deterministyczna.

— k0pernikus

1

Nigdy nie miałem problemu z yarn.locknieoczekiwaną aktualizacją (używam od października 2016 roku, kiedy to wyszło). Zawsze użytkownik robił coś ręcznie lub kiepski skrypt poinstalacyjny. To jest powód, dla którego wolę Przędzę niż NPM (NPM aktualizuje wszystko za każdym razem, kiedy chce). Myślę, że uważam się za szczęściarza, że nie wpadłem na te problemy.

— jkrehm

5

Z mojego doświadczenia wynika, że tak, powinniśmy zatwierdzić yarn.lockplik. Zapewni to, że gdy inne osoby będą korzystać z twojego projektu, uzyskają takie same zależności, jak Twój projekt się spodziewał.

Z dokumentu

Gdy uruchomisz przędzę lub dodaj przędzę, Yarn wygeneruje plik yarn.lock w katalogu głównym pakietu. Nie musisz czytać ani rozumieć tego pliku - po prostu zaznacz go w celu kontroli źródła. Gdy inne osoby zaczną używać Yarn zamiast npm, plik yarn.lock zapewni, że uzyskają dokładnie takie same zależności, jak ty.

Można argumentować, że możemy to osiągnąć, zastępując ^je --. Tak, możemy, ale generalnie widzieliśmy, że większość npmpakietów jest dostarczana z ^notacją i musimy ręcznie zmienić notację, aby zapewnić statyczną yarn.lockwersję zależności, ale jeśli go użyjesz , zapewni programowo poprawną wersję.

Również, jak powiedział tutaj Eric Elliott

Nie .gitignore yarn.lock. Ma na celu zapewnienie deterministycznego rozwiązywania zależności, aby uniknąć błędów „działa na moim komputerze”.

— Anszul
źródło

3

Tak, powinieneś to zrobić. Aby uzyskać więcej informacji na temat pliku yarn.lock, zapoznaj się z oficjalnymi dokumentami tutaj

— Navin prasad
źródło

3

Tak! yarn.lockmusi być zalogowany, aby każdy programista, który zainstaluje zależności, uzyskał dokładnie to samo wyjście! Na przykład z npm [który był dostępny w październiku 2016 r.] Możesz mieć patchlokalną wersję (powiedzmy 1.2.0) zainstalowaną lokalnie, podczas gdy nowy programista uruchamiający świeżą installwersję może otrzymać inną wersję (1.2.1).

— enapupe
źródło

1

Wspomniane zachowanie npm zależy od sposobu zapisywania zależności. Jeśli oszczędzasz --save-exactprzy użyciu npm, możesz osiągnąć to samo zachowanie.

— AlicanC

4

@AlicanC Nie sądzę, że to takie proste. Wierzę, że przędza (poprzez zatwierdzony plik blokady) zagwarantuje tę samą wersję pakietów i wszystkie ich zależności . Jest to coś, z czym NPM zawsze miał problem, ponieważ zależność zależności może nie być przypięta do konkretnej wersji, więc nowa instalacja może pociągać za sobą różne zależności niższego poziomu. Shrinkwrap NPM miał do pewnego stopnia rozwiązać ten problem, ale zawsze było to trudne i bardzo często nie działa poprawnie.

— nextgentech

@nextgentech W takim przypadku, w jaki sposób mam się upewnić, że zależność zależności jest odpowiednio aktualizowana. Załóżmy, że mam pakiet główny, który zawiera niektóre (powiedzmy 3) pakiety zależne. Będę obserwować zmiany w moim głównym pakiecie i zaktualizować go w pliku package.json. Ale jeśli którykolwiek z 3 pakietów podrzędnych jest przez nich aktualizowany, jak mogę uzyskać zmiany? Z powodu pliku blokady te zależności nie zostaną zaktualizowane, prawda?

— Pragatheeswaran,

Jeszcze się z tym nie bawiłem, ale uważam, że to właśnie tutaj yarn upgradewchodzi w grę polecenie. To polecenie uaktualni wszystkie pakiety i ponownie utworzy plik blokady. Na przykład, jeśli wdrażasz aplikację do produkcji i musisz zainstalować zależności, zrobiłoby to na podstawie pliku blokady pobranego z repozytorium. Nigdy nie należy uruchamiać, yarn upgradechyba że wyraźnie chcesz zmienić informacje o zależnościach (a tym samym zatwierdzić nowy plik blokady).

— nextgentech,

yarn installnie zapewni tych samych wersji. Tylko yarn install --frozen-lockfilerobi.

— k0pernikus