Jaka jest różnica między tyldą (~) a karetką (^) w pliku package.json?


3380

Po aktualizacji do najnowszej stabilnej wersji nodei npmspróbowałem npm install moment --save. Zapisuje wpis w prefiksie package.jsonkaretki ^. Wcześniej był to ~przedrostek tyldy .

  1. Dlaczego wprowadzono te zmiany npm?
  2. Jaka jest różnica między tyldą ~a karetką ^?
  3. Jakie są zalety w stosunku do innych?

42
FYI można zapobiec przedrostków lub użyć jednego niestandardowe robi: npm config set save-prefix=''. (Wstaw ~cytaty, jeśli tak wolisz.) Ja osobiście to robię i pakuję rzeczy do produkcji.
fncomp

19
Wszystkie drobiazgowe szczegóły na temat działania tyldy i karetki oraz różnice: github.com/npm/node-semver#tilde-ranges-123-12-1
Jeffrey Martinez

11
To narzędzie jest świetnym pomocnikiem do testowania semver.npmjs.com
chaiyachaiya

@fncomp chciałem tylko wyjaśnić, czy dobrze skomentowałem Twój komentarz. Czy używasz tylko określonych wersji zależności w swoim projekcie? nasz zespół waha się przed aktualizacją zależności. Czy zaleciłbyś użycie określonych wersji lub prefiksu „~” dla zależności?
blogs4t,

@fncomp, czy mógłbyś szczegółowo opisać, co masz na myśli mówiąc „osobiście to robię i zmniejszam koszty produkcji”. dzięki!
blogs4t,

Odpowiedzi:


3838

Zobacz dokumenty NPM i dokumenty semver

~ wersja „W przybliżeniu odpowiednik wersji”, zaktualizuje cię do wszystkich przyszłych wersji łatek, bez zwiększania wersji dodatkowej. ~1.2.3użyje wersji od 1.2.3 do <1.3.0.

^ wersja „Kompatybilny z wersją”, zaktualizuje cię do wszystkich przyszłych mniejszych wersji / łatek, bez zwiększania wersji głównej. ^2.3.4użyje wersji od 2.3.4 do <3.0.0.

Zobacz komentarze poniżej.


324
Publikowanie tutaj, miejmy nadzieję, że złapie ludzi, którzy nie do końca się nad tym zastanawiają, ale zarówno ^, jak i ~ zakładają, że możesz ufać niewielkim i punktowym uwolnieniom ze swoich zależności. Jeśli publikujesz bibliotekę i chcesz, aby inni Ci zaufali, NIE NALEŻY ŚREDNIO AKCEPTOWAĆ ZALEŻNOŚCI POZIOMU. Złe uwolnienie kropki z twojej zależności może spowodować reakcję łańcuchową w górę i spowoduje, że ludzie będą pukać do twoich drzwi, gdy sprawy przybierają kształt gruszki. To kolejny ogromny powód, aby używać npm shrinkwrap w kodzie produkcyjnym.
tehfoo,

8
Możesz także po prostu pozbyć się wszystkich bzdur, jak npm przygotowując swoje wersje za pomocą a ^lub a ~. Ustaw to, jeśli chcesz mieć ścisłą kontrolę nad swoimi wersjami: npm config set save-prefix=''
kumarharsh

5
@prasanthv ma rację: z docs.npmjs.com/misc/semver#caret-ranges-1-2-3-0-2-5-0-0-4 : Zakresy opieki ^ 1,2.3 ^ 0.2.5 ^ 0.0 .4. Zezwala na zmiany, które nie modyfikują skrajnie lewej niezerowej cyfry w krotce [głównej, drobnej, łatce]. Innymi słowy, pozwala to na łatanie i drobne aktualizacje dla wersji 1.0.0 i nowszych, na łatki dla wersji 0.X> = 0.1.0 i brak aktualizacji dla wersji 0.0.X.
rofrol,

15
@jgillich w semver, gdy używasz 0.2.x, 2nie jest major version. Dlatego docs.npmjs.com stosować konkretne słowa: the left-most non-zero digit. A co z tym przypadkiem: ^ 0,0.4 oznacza 0,0,4
rofrol

11
@FagnerBrack: Podany przykład jest poprawny, ale ogólnie twój sposób myślenia jest zły. Przykład: Załóżmy, że masz pakiet Aw 3 wersjach: 0.0.1, 0.0.2i 0.0.3. Wystąpił błąd, 0.0.1więc chcesz mieć przynajmniej 0.0.2w swoim pakiecie B. Jeśli napiszesz 0.0.x, dostaniesz 0.0.3, co jest OK. Ale jeśli jakiś inny pakiet Cwymaga obu, Ba Adodatkowo ma ograniczenia "A": "<0.0.2", dostaniesz je 0.0.1bez pokazywania problemu konfliktu, co nie jest tym, czego chcesz. Użycie tyldy ~0.0.2powinno pomóc uniknąć tego problemu.
Maciej Sz

861

Chciałbym również dodać oficjalną dokumentację npmjs, która opisuje wszystkie metody specyficzności wersji, w tym te, o których mowa w pytaniu -

https://docs.npmjs.com/files/package.json

https://docs.npmjs.com/misc/semver#x-ranges-12x-1x-12-

  • ~version „W przybliżeniu odpowiednik wersji” Patrz npm semver - Tilde Ranges & semver (7)
  • ^version „Kompatybilny z wersją” Patrz npm semver - Caret Ranges & semver (7)
  • version Musi dokładnie pasować do wersji
  • >version Musi być większy niż wersja
  • >=version itp
  • <version
  • <=version
  • 1.2.x 1.2.0, 1.2.1 itd., Ale nie 1.3.0
  • http://sometarballurl (może to być adres URL tarballa, który zostanie pobrany i zainstalowany lokalnie
  • * Pasuje do dowolnej wersji
  • latest Otrzymuje najnowszą wersję

Powyższa lista nie jest wyczerpująca. Inne specyfikatory wersji obejmują adresy URL GitHub i repozytorium użytkowników GitHub, lokalne ścieżki i pakiety ze specyficznymi tagami npm


8
Możliwe jest również określenie dokładnego zakresu wersji, takich jak 1.2.0 || >=1.2.2 <1.3.0: Dokładnie 1.2.0 lub wszystko od 1.2.2 do 1.3.0 (włącznie), ale nie 1.2.1 lub 1.3.1 i wyżej, a także nie 1.1 .x i poniżej.
CodeManX

Bardziej szczegółowy link z powyższego -> docs.npmjs.com/files/package.json#dependencies
Toby

"Approximately equivalent to version"i "Compatible with version"są tak frustrująco niespecyficznymi sposobami opisywania zachowania ~ i ^. Dziękuję @jgillich za udzielenie rzeczywistej odpowiedzi!
Scott Stafford,

635

npm pozwala na zainstalowanie nowszej wersji pakietu niż podana. Użycie tilde ( ~) daje ci poprawki błędów, a caret ( ^) daje także nową kompatybilność wsteczną.

Problem polega na tym, że stare wersje zwykle nie otrzymują zbyt wiele poprawek, więc npm używa ^domyślnie caret ( ) --save.

stół semver

Według: „Semver wyjaśnił - dlaczego w mojej paczce.json jest znak karetki (^)?” .

Należy pamiętać, że reguły dotyczą wersji powyżej 1.0.0 i nie każdy projekt jest zgodny z wersją semantyczną. W wersjach 0.xx daszek dopuszcza tylko aktualizacje łatek , tzn. Zachowuje się tak samo jak tylda. Zobacz „Zakresy Caret”

Oto wizualne wyjaśnienie pojęć:

schemat semver

Źródło: „Semantyczna wersja Cheatheet” .


2
Co powiesz na ^ 0.2.5? from docs.npmjs.com/misc/semver#caret-ranges-1-2-3-0-2-5-0-0-4 : Zakresy Careta ^ 1,2.3 ^ 0,2,5 ^ 0,0.4. Zezwala na zmiany, które nie modyfikują najbardziej niezerowej cyfry z lewej strony w krotce [główna, drobna, łatka]. Innymi słowy, umożliwia to stosowanie poprawek i drobnych aktualizacji dla wersji 1.0.0 i nowszych, aktualizacji łatek dla wersji 0.X> = 0.1.0 i brak aktualizacji dla wersji 0.0.X.
rofrol,

11
@rofrol dowolną wersję wcześniejszą niż 1.0.0 uważa się za niestabilną i te zasady nie mają zastosowania
pspi

2
Więc twoje wyjaśnienie nie jest kompletne
rofrol

5
@rofrol tak, czasami pomijanie dla czytelności jest dobre, szanse na coś poniżej 1.0.0 dla zależności w pakiecie json są dość niskie. patrz także zasada 20/80, to świetna zasada skupiania się na tym, co ważne
pspi

1
@pspi Posiadanie wersji poniżej 1.0.0 jest „mało prawdopodobne”? Na 60 mamy ~ 15, a większość z nich nie jest nieznana.
Dave Newton,

99

Semver

<major>.<minor>.<patch>-beta.<beta> == 1.2.3-beta.2
  • Użyj kalkulatora semm npm do testowania. (Chociaż wyjaśnienia dla ^ (obejmują wszystko większe niż konkretna wersja w tym samym głównym zakresie) i ~ (obejmują wszystko większe niż konkretna wersja w tym samym mniejszym zakresie) nie są w 100% poprawne, kalkulator wydaje się działać dobrze )
  • Ewentualnie użyj zamiast tego SemVer Check , który nie wymaga wybrania pakietu, a także oferuje wyjaśnienia.

Zezwalaj lub nie zezwalaj na zmiany

  • Wersja PIN: 1.2.3.
  • Użyj ^(jak głowa). Umożliwia aktualizacje na drugim niezerowym poziomie od lewej: ^0.2.3oznacza 0.2.3 <= v < 0.3.
  • Użyj ~(jak ogon). Zasadniczo zamroź poziom najbardziej w prawo lub ustaw zero, jeśli zostanie pominięty:
    • ~1 znaczy 1.0.0 <= v < 2.0.0
    • ~1.2środki 1.2.0 <= v < 1.3.0.
    • ~1.2.4środki 1.2.4 <= v < 1.3.0.
  • Ommit najwyższy poziom: 0.2oznacza 0.2 <= v < 1. Różni się od ~:
    • Uruchamianie wersji z pominiętym poziomem jest zawsze 0
    • Można ustawić początkową wersję główną bez określania podpoziomów.

Wszystkie (miejmy nadzieję) możliwości

Ustaw początkowy poziom główny i zezwalaj na aktualizacje w górę

*  or "(empty string)   any version
1                         v >= 1

Zatrzymaj główny poziom

~0 (0)            0.0 <= v < 1
0.2               0.2 <= v < 1          // Can't do that with ^ or ~ 
~1 (1, ^1)        1 <= v < 2
^1.2              1.2 <= v < 2
^1.2.3            1.2.3 <= v < 2
^1.2.3-beta.4     1.2.3-beta.4 <= v < 2

Zablokuj mniejszy poziom

^0.0 (0.0)        0 <= v < 0.1
~0.2              0.2 <= v < 0.3
~1.2              1.2 <= v < 1.3
~0.2.3 (^0.2.3)   0.2.3 <= v < 0.3
~1.2.3            1.2.3 <= v < 1.3

Zatrzymaj poziom łaty

~1.2.3-beta.4     1.2.3-beta.4 <= v < 1.2.4 (only beta or pr allowed)
^0.0.3-beta       0.0.3-beta.0 <= v < 0.0.4 or 0.0.3-pr.0 <= v < 0.0.4 (only beta or pr allowed)
^0.0.3-beta.4     0.0.3-beta.4 <= v < 0.0.4 or 0.0.3-pr.4 <= v < 0.0.4 (only beta or pr allowed)

Nie zezwalaj na aktualizacje

1.2.3             1.2.3
^0.0.3 (0.0.3)    0.0.3

Uwaga : brakujące dane główne, drobne, poprawki lub specyfikacjebeta bez numeru jest takie samo jak anydla brakującego poziomu.

Uwaga : Po zainstalowaniu pakietu, który ma 0poziom główny, aktualizacja zainstaluje tylko nową wersję beta / pr! To dlatego, że npmzestawy ^package.jsonustawione domyślnie w, a wersja zainstalowana jest podobna0.1.3 , zamraża wszystkie poziomy główne / drobne / poprawki.


Mówienie ludziom, aby unikali rozpoczynania projektów od zera, ponieważ biblioteka i konsumenci programiści nie rozumieją, że system jest strasznym rozwiązaniem. Myślę, że @asdfasdfads ma znacznie lepsze informacje.
ProLoser

@ProLoser Po prostu uważam, że system powinien zostać uproszczony i nie powinniśmy używać wersji 0.x.
rofrol

1
Przypadek użycia związany z wczesnym rozwojem cyklu życia i wersją v0 ma DUŻO sensu. Uczenie się, jak v0 zachowuje się właściwie, sprawiło, że z niecierpliwością czekam na inne projekty na wczesnym etapie życia. Oznacza to, że możesz mieć szybko zmieniający się interfejs API z wieloma niezgodnościami wstecznymi bez konieczności deklarowania projektu jako 1.x (inaczej: stabilny), gdy tak naprawdę nie jest.
ProLoser

Rozumiem, ale po prostu nie podoba mi się, jak to działa z semver i kwalifikatorami
rofrol

2
To bardziej przypomina opinię i nie powinno być traktowane jako ogólnie przyjęte podejście. I ^ 0.1.x robi łatki idealnie.
ProLoser,

93

~naprawia duże i mniejsze liczby. Jest używany, gdy jesteś gotowy zaakceptować poprawki błędów w swojej zależności, ale nie chcesz żadnych potencjalnie niezgodnych zmian.

^naprawia tylko numer główny. Jest używany, gdy uważnie obserwujesz swoje zależności i jesteś gotowy, aby szybko zmienić kod, jeśli drobne wydanie będzie niezgodne.

Ponadto nie^ jest obsługiwany przez starsze wersje npm i należy go używać ostrożnie.

Tak więc ^jest dobrym domyślnym, ale nie jest doskonały. Sugeruję staranne wybranie i skonfigurowanie najbardziej przydatnego dla ciebie operatora semver.


13
nieprawda: zakresy karetki ^ 1,2.3 ^ 0,2,5 ^ 0,0.4. Zezwala na zmiany, które nie modyfikują najbardziej niezerowej cyfry z lewej strony w krotce [główna, drobna, łatka]. Innymi słowy, umożliwia to stosowanie poprawek i drobnych aktualizacji dla wersji 1.0.0 i nowszych, aktualizacji łatek dla wersji 0.X> = 0.1.0 i brak aktualizacji dla wersji 0.0.X. docs.npmjs.com/misc/semver#caret-ranges-1-2-3-0-2-5-0-0-4
rofrol

6
Ta odpowiedź jest całkowicie błędna (jak wiele innych tutaj). Żaden z nich nigdy nie naprawia większej liczby! Jak powiedział @rofrol, ^ po prostu utrzymuje lewą najbardziej niezerową cyfrę bez zmian. ~ z drugiej strony zezwala na aktualizacje łat tylko wtedy, gdy podana jest wersja podrzędna (np. ~ 1.2.3 lub ~ 1.2) i zezwala na drobne aktualizacje, jeśli wersja podrzędna nie jest podana (np. ~ 1).
TheBaj

2
@TheBaj Mają na myśli „naprawić” jako „zdefiniować” („naprawić”), a nie „dostosować”, więc wszyscy zgadzacie się, w jaki sposób obsługiwana jest większa liczba.
maaartinus,

1
Tak, ta odpowiedź wydawała się całkowicie odwrócona, dopóki nie zdałem sobie sprawy, że odpowiadający miał na myśli „naprawić” jak w „zrobić to, co stałe, stacjonarne lub niezmienne”.
NattyC,

57

~: Dość blisko do

   ~1.1.5: 1.1.0 <= accepted < 1.2.0

^: Kompatybilny z

   ^1.1.5: 1.1.5 <= accepted < 2.0.0

   ^0.1.3: 0.1.3 <= accepted < 0.2.0

   ^0.0.4: 0.0.4 <= accepted < 0.1.0

17
@kytwb - nie. W szczególnym przypadku numerów wersji z zerami zerowymi karat jest równoważny z tyldy. Dlatego ^0.1.3akceptuje tylko wersje 0.1.xi nie akceptuje 0.2.0, nawet jeśli jest to niewielki przyrost. To zachowanie jest równoważne z ~0.1.3. Przyczyna tego zachowania wynika z faktu, że pakiety zerowania są nadal uważane za niestabilne; słowami semver.org , nr 4, „wszystko może się zmienić w dowolnym momencie” (w tym zmiany niezgodne wstecz).
chharvey

31

^to 1. [dowolne]. [dowolne] (najnowsza wersja pomocnicza)
~to 1.2. [dowolne] (najnowsza łatka)

Świetnie przeczytano ten post na blogu, w jaki sposób semver odnosi się do npm
i co robią, aby dopasować go do standardu semver
http://blog.npmjs.org/post/98131109725/npm-2-0-0


2
nieprawda: zakresy karetki ^ 1,2.3 ^ 0,2,5 ^ 0,0.4. Zezwala na zmiany, które nie modyfikują najbardziej niezerowej cyfry z lewej strony w krotce [główna, drobna, łatka]. Innymi słowy, umożliwia to stosowanie poprawek i drobnych aktualizacji dla wersji 1.0.0 i nowszych, aktualizacji łatek dla wersji 0.X> = 0.1.0 i brak aktualizacji dla wersji 0.0.X. docs.npmjs.com/misc/semver#caret-ranges-1-2-3-0-2-5-0-0-4
rofrol

28

Dopasowywanie kapelusza można uznać za „zepsute”, ponieważ nie zostanie zaktualizowane ^0.1.2do 0.2.0. Kiedy pojawi się oprogramowanie, użyj 0.x.ywersji i dopasowuj hat dopasuje tylko ostatnią zmienną cyfrę ( y). Odbywa się to celowo. Powodem jest to, że gdy oprogramowanie ewoluuje, interfejs API zmienia się gwałtownie: pewnego dnia masz te metody, a drugiego masz te metody i starych już nie ma. Jeśli nie chcesz łamać kodu osobom, które już korzystają z twojej biblioteki, idź i zwiększ wersję główną: np. 1.0.0-> 2.0.0-> 3.0.0. Tak więc, zanim Twoje oprogramowanie będzie w 100% gotowe i będzie w pełni funkcjonalne, będzie to jak wersja, 11.0.0która nie będzie wyglądać na znaczącą i faktycznie będzie myląca. Jeśli natomiast używałeś0.1.x ->0.2.x-> 0.3.xwersje, zanim oprogramowanie zostanie w 100% gotowe i będzie w pełni funkcjonalne, zostanie wydane jako wersja, 1.0.0co oznacza: „To wydanie jest usługą długoterminową, możesz kontynuować korzystanie z tej wersji biblioteki w swojej produkcji kodu, a autor nie zmieni wszystkiego jutro lub w przyszłym miesiącu i nie porzuci pakietu ".

Zasada jest taka: używaj 0.x.ywersji, gdy oprogramowanie nie jest jeszcze dojrzałe, i zwolnij ją, zwiększając środkową cyfrę, gdy zmienia się publiczny interfejs API (dlatego osoby, ^0.1.0które nie otrzymają 0.2.0aktualizacji i nie złamią swojego kodu). Następnie, gdy oprogramowanie dojrzeje, zwolnij go 1.0.0i zwiększaj lewą cyfrę za każdym razem, gdy zmienia się twój publiczny interfejs API (dlatego ludzie ^1.0.0nie otrzymają 2.0.0aktualizacji i nie złamie ich kodu).

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

Ten komentarz był absurdalnie pomocny i nie wydaje się być dobrze udokumentowany. Czy masz link do dokumentacji dotyczącej tego zachowania? Ta odpowiedź na temat projektów v0 bardzo mi pomogła.
ProLoser

Nie mam linku: te informacje też znalazłem, przeglądając go i grając przy użyciu npm semantycznego kalkulatora wersji semm semver.npmjs.com
catamphetamine

2
Należy dodać do ich dokumentacji w bardziej formalny sposób. Rozmawiałem w Sony z moim zespołem inżynierów, ponieważ wydaje się, że tak łatwo go przeoczyć. slides.com/proloser/semver-v0
ProLoser

24

~ Tylda:

  • ~zawiesza liczby większe i mniejsze.
  • Jest używany, gdy jesteś gotowy zaakceptować poprawki błędów w swojej zależności, ale nie chcesz żadnych potencjalnie niezgodnych zmian.
  • Tylda odpowiada najnowszej pomniejszej wersji (środkowa liczba).
  • ~ 1.2.3 będzie pasowało do wszystkich wersji 1.2.x, ale będzie brakowało 1.3.0.
  • Tilde (~) daje ci poprawki błędów

^ Caret:

  • ^ zamraża tylko numer główny.
  • Jest używany, gdy uważnie obserwujesz swoje zależności i jesteś gotowy, aby szybko zmienić kod, jeśli drobne wydanie będzie niezgodne.
  • Spowoduje to zaktualizowanie do najnowszej wersji głównej (pierwszy numer).
  • ^ 1.2.3 będzie pasować do dowolnej wersji 1.xx, w tym 1.3.0, ale będzie się utrzymywać w wersji 2.0.0.
  • Caret (^) zapewnia także nową funkcjonalność kompatybilną wstecz.

1
Tylda odpowiada najnowszej wersji łatki (ostatni numer). Kursor pasuje do najnowszej pomniejszej wersji (środkowa liczba).
Abdul Rauf

„zamrożenie” jest najlepszym wytłumaczeniem.
mhrabiee

Caret zarówno zawiesza numer główny, jak i aktualizuje do najnowszej wersji głównej (pierwszy numer)? Większa liczba jest pierwszą liczbą, więc nie ma to sensu.
NattyC

19

Tilde ~ pasuje do mniejszej wersji, jeśli zainstalowałeś pakiet, który ma 1.4.2, a po instalacji wersje 1.4.3 i 1.4.4 są również dostępne, jeśli w pakiecie.json jest używany jako ~ 1.4.2, a następnie instalacja npm w twoim projekcie po aktualizacji zainstaluje 1.4.4 w twoim projekcie. Ale dla tego pakietu jest dostępna wersja 1.5.0, więc nie zostanie on zainstalowany przez ~. Nazywa się to wersją podrzędną.

Caret ^ pasuje do głównej wersji, jeśli pakiet 1.4.2 jest zainstalowany w twoim projekcie, a po wydaniu instalacji 1.5.0, ^ zainstaluje główną wersję. Nie pozwoli zainstalować 2.1.0, jeśli masz ^ 1.4.2 .

Naprawiono wersję, jeśli nie chcesz zmieniać wersji pakietu przy każdej instalacji, a następnie użyłeś stałej wersji bez żadnego znaku specjalnego, np. „1.4.2”

Najnowsza wersja * Jeśli chcesz zainstalować najnowszą wersję, używaj * tylko przed nazwą pakietu.


3
Ta odpowiedź jest myląca. SemVer wyraźnie stwierdza, że normalny numer wersji MUSI przybrać postać XYZ [gdzie] X jest wersją główną, Y to wersja dodatkowa, a Z to wersja poprawki.
Leo

15

Objaśnienie jednego linera

Standardowy system wersjonowania to major.minor.build (np. 2.4.1)

npm sprawdza i naprawia wersję konkretnego pakietu na podstawie tych znaków

~ : poprawiono wersję główną, poprawiono wersję podrzędną, pasuje do dowolnego numeru kompilacji

np .: ~ 2.4.1 oznacza, że ​​sprawdzi, czy 2.4.x gdzie x jest cokolwiek

^ : poprawiono wersję główną, pasuje do dowolnej wersji pomocniczej, pasuje do dowolnego numeru kompilacji

np .: ^ 2.4.1 oznacza, że ​​sprawdzi 2.xx gdzie x jest czymkolwiek


5
Widzę 7 linii w tej odpowiedzi
FluxLemur

11

Prawdopodobnie widziałeś tyldę (~) i karetkę (^) w pliku package.json. Jaka jest różnica między nimi?

Kiedy wykonasz npm moment instalacji --save, zapisuje on wpis w pliku package.json z prefiksem daszka (^).

Tylda (~)

Mówiąc najprościej, tylda (~) odpowiada najnowszej wersji dodatkowej (środkowej liczbie). ~ 1.2.3 pasuje do wszystkich wersji 1.2.x, ale brakuje wersji 1.3.0.

Karetka (^)

Natomiast daszek (^) jest bardziej zrelaksowany. Spowoduje to zaktualizowanie do najnowszej wersji głównej (pierwszy numer). ^ 1.2.3 będzie pasować do dowolnej wersji 1.xx, w tym 1.3.0, ale wstrzyma się z wersją 2.0.0.

Odniesienie: https://medium.com/@Hardy2151/caret-and-tilde-in-package-json-57f1cbbe347b


Ponownie ta odpowiedź jest myląca. SemVer wyraźnie stwierdza, że normalny numer wersji MUSI przybrać postać XYZ [gdzie] X jest wersją główną, Y to wersja dodatkowa, a Z to wersja poprawki.
Leo

5

semver jest podzielony na 3 główne sekcje, które są podzielone kropkami.

major.minor.patch
1.0.0

Te różne główne, drobne i łatki służą do identyfikacji różnych wydań. tide (~) i caret (^) używają do określenia, która wersja pomocnicza i łatka ma być używana w wersji pakietu.

~1.0.1
 Install 1.0.1 or **latest patch versions** such as 1.0.2 ,1.0.5
^1.0.1
 Install 1.0.1 or **latest patch and minor versions** such as 1.0.2 ,1.1.0 ,1.1.1

4

Tylda (~)

poprawiono wersję główną, poprawiono wersję podrzędną, pasuje ona do dowolnego numeru kompilacji

"express": "~4.13.3" 

~4.13.3 oznacza, że ​​sprawdzi 4.13.x gdzie x jest czymkolwiek i 4.14.0

Caret (^)

główna wersja jest naprawiona, pasuje do dowolnej mniejszej wersji, pasuje do dowolnego numeru kompilacji

"supertest": "^3.0.0"

^3.0.0 oznacza, że ​​sprawdzi 3.xx gdzie x jest czymkolwiek


Czy możesz wyjaśnić, w jaki sposób ta odpowiedź różni się od tej samej odpowiedzi opublikowanej 4 lata temu ?
Franklin Yu,

2

Numer wersji ma składnię, która oznacza każdą sekcję o innym znaczeniu. składnia jest podzielona na trzy sekcje oddzielone kropką.

major.minor.patch 1.0.2

Major, minor i patch reprezentują różne wersje pakietu.

npm używa tyldy (~) i karetki (^) do określenia, której łatki i mniejszych wersji użyć.

Jeśli więc zobaczysz ~ 1.0.2, oznacza to zainstalowanie wersji 1.0.2 lub najnowszej wersji poprawki, takiej jak 1.0.4. Jeśli zobaczysz ^ 1.0.2, oznacza to zainstalowanie wersji 1.0.2 lub najnowszej wersji podrzędnej lub łatki, takiej jak 1.1.0.


1
Czy możesz wyjaśnić, w jaki sposób ta odpowiedź różni się od tej samej odpowiedzi opublikowanej 4 lata temu ?
Franklin Yu,

2

karat ^ obejmuje wszystko większe niż konkretna wersja z tego samego głównego zakresu.

tylda ~ obejmuje wszystko większe niż konkretna wersja z tego samego pomniejszego zakresu.

Na przykład, aby określić dopuszczalne zakresy wersji do 1.0.4, użyj następującej składni:

  • Wersje łatek: 1.0 lub 1.0.x lub ~ 1.0.4
  • Drobne wydania: 1 lub 1.x lub ^ 1.0.4
  • Najważniejsze wydania: * lub x

Aby uzyskać więcej informacji na temat składni wersjonowania semantycznego, zobacz kalkulator npm semver .

npm wersje semantyczne w opublikowanych pakietach§

Więcej z dokumentacji npm O wersjach semantycznych


1

Nie jest to odpowiedź sama w sobie, ale spostrzeżenie, które wydaje się być przeoczone.

Opis zakresów karatowych:

patrz: https://github.com/npm/node-semver#caret-ranges-123-025-004

Zezwala na zmiany, które nie modyfikują najbardziej niezerowej cyfry z lewej strony w krotce [główna, drobna, łatka].

Oznacza, że ^10.2.3pasuje10.2.3 <= v < 20.0.0

Nie sądzę, że o to im chodziło. Pobieranie wersji od 11.xx do 19.xx spowoduje uszkodzenie kodu.

Myślę, że mieli na myśli left most non-zero number field. W SemVer nie ma nic, co wymagałoby jednocyfrowego pola liczbowego.



0

W związku z tym pytaniem możesz przejrzeć dokumentację Composer dotyczącą wersji , ale w skrócie:

  • Zakres wersji tyldy ( ~ ) - ~ 1.2.3 odpowiada> = 1.2.3 < 1.3.0
  • Zakres wersji Careta ( ^ ) - ~ 1.2.3 jest równoważny> = 1.2.3 < 2.0.0

Tak więc, dzięki Tilde będziesz otrzymywać automatyczne aktualizacje łat, ale mniejsze i większe wersje nie będą aktualizowane. Jednakże, jeśli użyjesz Caret , dostaniesz łatki i mniejsze wersje, ale nie dostaniesz głównych (przełamujących zmiany) wersji.

Wersja Tilde jest uważana za „bezpieczniejszą”, ale jeśli używasz niezawodnych zależności (dobrze utrzymanych bibliotek), nie powinieneś mieć żadnych problemów z wersją Caret (ponieważ drobne zmiany nie powinny niszczyć zmian.

Prawdopodobnie powinieneś zapoznać się z tym postem dotyczącym przepływu stosu na temat różnic między instalacją kompozytora a aktualizacją kompozytora .

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.