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


Po aktualizacji do najnowszej stabilnej node i npm, Próbowałem npm install moment --save. Zapisuje wpis w package.json z caret(^) prefiks. Wcześniej był to tilde(~) prefiks.

  1. Dlaczego te zmiany wprowadzono w npm?
  2. Jaka jest różnica pomiędzy tilde(~) i caret(^)?
  3. Jakie są zalety w stosunku do innych?

2249
2018-03-12 06:02


pochodzenie


FYI możesz zapobiec przedrostkami lub użyć niestandardowego: npm config set save-prefix=''. (Kij ~ w cudzysłowach, jeśli wolisz.) Osobiście to robię i piszę do rzeczy w produkcji. - fncomp
Wszystkie szczegółowe informacje na temat działania tyldy i opiekuna oraz różnic: github.com/npm/node-semver#tilde-ranges-123-12-1 - Jeffrey Martinez
To narzędzie jest doskonałym pomocnikiem do testowania semver.npmjs.com - chaiyachaiya
@fncomp chciał tylko wyjaśnić, czy twój komentarz jest właściwy ... czy używasz tylko określonych wersji zależności w swoim projekcie? nasz zespół waha się przed aktualizacją zależności. Czy poleciłbyś używać konkretnych wersji lub przedrostka '~' dla zależności? - blogs4t
@fncomp możesz szczegółowo opisać, co masz na myśli mówiąc "Ja osobiście to robię i pakuję rzeczy do produkcji". dzięki! - blogs4t


Odpowiedzi:


W najprostszym ujęciu tylda pasuje do najnowszej wersji pomniejszej   (środkowy numer). ~ 1.2.3 będzie pasować do wszystkich wersji 1.2.x, ale będzie   brak 1.3.0.

Z drugiej strony strażnik jest bardziej zrelaksowany. To zaktualizuje cię do   najnowsza wersja główna (pierwszy numer). ^ 1.2.3 będzie pasować   każda wersja 1.x.x, w tym 1.3.0, ale pozostanie w wersji 2.0.0.

http://fredkschott.com/post/2014/02/npm-no-longer-defaults-to-tildes/


2640
2018-03-12 08:28



Publikowanie tutaj, aby miejmy nadzieję, złapać ludzi, którzy nie całkiem to przemyśleć, ale zarówno ^ jak i ~ zakłada, że ​​możesz zaufać mniejszym i punktowym uwolnieniom z twoich zależności. Jeśli publikujesz bibliotekę i chcesz, aby inni ludzie Ci ufali, NIE WOLNO PRZYJMUJ ZGODNIE Z ZALICZKAMI DALEJMI. Złe wydanie kropki z twojej zależności może spowodować reakcję łańcuchową w górę rzeki, i ludzie będą pukać do TWOICH drzwi, gdy wszystko zmieni się w gruszkę. Jest to kolejny ogromny powód użycia npm shrinkwrap na twoim kodzie produkcyjnym. - tehfoo
To jest mylące dla ^. Tu jest napisane ^  zaktualizuje Cię do najnowszego poważny wersja, w rzeczywistości aktualizuje cię do najnowszej mniejszy wersja. tj .: - ^ 1.2.3: => = 1.2.3 <2.0.0 - ^ 0.2.3: => = 0.2.3 <0.3.0 - ^ 0.0.3: => = 0.0.3 <0.0.4 - prasanthv
@jgillich w semwerze, gdy używasz 0.2.x, 2 nie jest major version. Dlatego docs.npmjs.com użył konkretnych słów: the left-most non-zero digit. A co z tym przypadkiem: ^ 0.0.4 oznacza 0.0.4 - rofrol
@FagnerBrack: Podany przykład jest poprawny, ale ogólnie twój sposób myślenia jest błędny. Przykład: załóżmy, że masz pakiet A w 3 wersjach: 0.0.1, 0.0.2 i 0.0.3. Występuje błąd 0.0.1 więc chcesz mieć co najmniej 0.0.2 w twoim pakiecie B. Jeśli piszesz 0.0.x dostaniesz 0.0.3, co jest w porządku. Ale jeśli jakieś inne opakowanie C wymaga obu B i A i dodatkowo ma ograniczenia "A": "<0.0.2" dostaniesz 0.0.1 bez pokazywania konfliktu, który nie jest tym, czego potrzebujesz. Używanie tyldy ~0.0.2 powinien pomóc Ci uniknąć tego problemu. - Maciej Sz
Dziwne, że ta błędna odpowiedź It will update you to the most recent major version ma 2k + upvotes. Zastanawiam się, ilu ludzi myśli teraz o tym ^ aktualizuje główną wersję !! Nie ma dwuznaczności co do tego, co major / minor / patch oznacza w wersji semserv - jest po prostu błędne - Drenai


Chciałbym 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 równoważny wersji" Zobacz npm semver - Tilde Ranges & semver (7)
  • ^version "Kompatybilny z wersją" Zobacz 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 archiwum, które zostanie pobrane i zainstalowane lokalnie
  • * Pasuje do dowolnej wersji
  • latest Otrzymuje najnowszą wersję

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


571
2017-09-16 06:25



Możliwe jest również określenie dokładnego zakresu wersji, na przykład 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
@CoDEmanX dlaczego 1.3.0 jest włączone, jeśli używasz <? - Janus Troelsen
Moje złe, to miało czytać <=1.3.0. - CoDEmanX
Czy jest możliwe 1.x.x? - Venryx
@Venryx tak, jest. To będzie każda wersja> = 1.0.0 i <2.0.0 - Ahmad


Npm pozwala zainstalować nowszą wersję pakietu niż określona. Używanie tyldy (~) daje poprawki błędów i opiekę (^) zapewnia także wsteczną kompatybilność nowych funkcji.

Problem polega na tym, że stare wersje zazwyczaj nie otrzymują tak dużo poprawek, więc npm używa caret (^) jako domyślny dla --save.

semver table

Według: "Semver wyjaśnił - dlaczego w moim package.json jest daszek (^)?".

Uwaga że zasady dotyczą wersji powyżej 1.0.0, a nie każdy projekt jest zgodny z wersją semantyczną. W wersjach 0.x.x dozwolony jest tylko karetka łata aktualizacje, tj. zachowuje się tak samo jak tylda. Widzieć "Rozstępy Caret"

Oto wizualne wyjaśnienie pojęć:

semver diagram

Źródło: "Semantic Versioning Cheatsheet".


349
2017-07-30 20:40



A co z ^ 0.2.5? od docs.npmjs.com/misc/semver#caret-ranges-1-2-3-0-2-5-0-0-4: Caret Ranges ^ 1.2.3 ^ 0.2.5 ^ 0.0.4. Pozwala na zmiany, które nie modyfikują lewej, niezerowej cyfry w krotce [dur, minor, patch]. Innymi słowy, pozwala to na aktualizację łatek i mniejszych wersji dla wersji 1.0.0 i nowszych, aktualizacje łat dla wersji 0.X> = 0.1.0 oraz aktualizacje dla wersji 0.0.X. - rofrol
@rofrol dowolnej wersji, zanim 1.0.0 jest uważany za niestabilny i te zasady nie mają zastosowania - pspi
Twoje wyjaśnienie nie jest kompletne - rofrol
@rofrol tak, pomijanie czytelności jest czasami dobre, szanse na posiadanie czegokolwiek poniżej 1.0.0 dla zależności w pakiecie json są dość niskie. patrz także zasada 20/80, to świetna zasada, aby skupić się na tym, co ważne - pspi
Zobacz moją odpowiedź. Co myślisz? stackoverflow.com/questions/22343224/... - rofrol


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

^ naprawia tylko główną liczbę. Jest używany, gdy uważnie przyglądasz się zależnościom i jesteś gotowy na szybką zmianę kodu, jeśli niewielkie wydanie będzie niezgodne.

W dodatku, ^ jest Nieobsługiwany przez stare wersje npm i powinny być używane z ostrożnością.

Więc, ^ jest dobrym domyślnym, ale nie jest doskonały. Sugeruję ostrożne wybieranie i konfigurowanie najbardziej przydatnego dla Ciebie operatora semver.


74
2018-03-12 23:05



not true: Caret Ranges ^ 1.2.3 ^ 0.2.5 ^ 0.0.4. Pozwala na zmiany, które nie modyfikują lewej, niezerowej cyfry w krotce [dur, minor, patch]. Innymi słowy, pozwala to na aktualizację łatek i mniejszych wersji dla wersji 1.0.0 i nowszych, aktualizacje łat dla wersji 0.X> = 0.1.0 oraz aktualizacje dla wersji 0.0.X. docs.npmjs.com/misc/semver#caret-ranges-1-2-3-0-2-5-0-0-4 - rofrol
Ta odpowiedź jest całkowicie błędna (tak jak wiele innych tutaj). Żadna z nich nigdy nie naprawiła większej liczby! Jak powiedział @rofrol, ^ po prostu utrzymuje niezmienioną lewą najbardziej niezerową cyfrę. ~ z drugiej strony zezwala tylko na aktualizacje łatek, jeśli określona jest wersja podrzędna (na przykład ~ 1.2.3 lub ~ 1.2) i zezwala na drobne aktualizacje, jeśli nie została podana wersja podrzędna (na przykład ~ 1). - TheBaj
@ TheBaj Mają na myśli "napraw" jako "zdefiniuj" ("napraw"), a nie "dostosuj", więc wszyscy zgadzają się, jak traktuje się główną liczbę. - maaartinus


Semver

<major>.<minor>.<patch>-beta.<beta> == 1.2.3-beta.2
  • Posługiwać się Kalkulator semp npm dla testów. (Chociaż wyjaśnienia dla ^ (obejmują wszystko większe niż konkretna wersja w tym samym zakresie głównym) i ~ (zawierają wszystko, co jest większe niż konkretna wersja w tym samym mniejszym zakresie) nie są w 100% poprawne, kalkulator wydaje się działać dobrze )
  • Ewentualnie użyj SemVer Check zamiast tego, co nie wymaga wybrania paczki, a także oferuje wyjaśnienia.

Zezwalaj lub nie zezwalaj na zmiany

  • Wersja pinowa: 1.2.3.
  • Posługiwać się ^ (jak głowa). Zezwala na aktualizacje na drugim niezerowym poziomie od lewej: ^0.2.3 znaczy 0.2.3 <= v < 0.3.
  • Posługiwać się ~ (jak ogon). Zwykle zamroź najbardziej na prawo poziom lub ustaw zero, jeśli pominięte:
    • ~1 znaczy 1.0.0 <= v < 2.0.0
    • ~1.2 znaczy 1.2.0 <= v < 1.3.0.
    • ~1.2.4 znaczy 1.2.4 <= v < 1.3.0.
  • Ommit prawy najwyższy poziom: 0.2 znaczy 0.2 <= v < 1. Różni się od ~ bo:
    • Rozpoczęcie pominiętej wersji poziomu jest zawsze 0
    • Możesz ustawić początkową wersję główną bez określania podpoziomów.

Wszystkie (mam nadzieję) możliwości

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

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

Zablokuj 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

Zablokuj poziom poprawek

~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

Ogłoszenie: Missing major, minor, patch lub specifying beta bez numeru, jest taki sam jak any dla brakującego poziomu.

Ogłoszenie: Kiedy instalujesz pakiet, który ma 0 jako główny poziom, aktualizacja zainstaluje tylko nową wersję wersji beta / pr! To jest ponieważ npm zestawy ^ jako domyślny w package.json i kiedy jest zainstalowana wersja 0.1.3, zamraża wszystkie główne / drobne / łatki.


66
2017-10-11 16:52



Mówienie ludziom, aby unikali rozpoczynania projektów od 0, ponieważ biblioteka i konsumenci nie rozumieją, że system to straszne rozwiązanie. Myślę, że @asdfasdfads ma o wiele lepsze informacje. - ProLoser
@ProLoser Po prostu uważam, że system powinien zostać uproszczony i nie powinniśmy używać wersji 0.x. - rofrol
Przypadek użycia wczesnego rozwoju cyklu życia i v0 ma dużo sensu. Uczenie się prawidłowego działania v0 sprawiło, że zacząłem oczekiwać innych projektów z wczesnego cyklu życia. Oznacza to, że możesz mieć szybko zmieniający się interfejs API z dużą ilością wstecznej niezgodności bez konieczności deklarowania projektu jako 1.x (vel: stable), gdy tak naprawdę nie jest. - ProLoser
Rozumiem, ale po prostu nie podoba mi się, jak to działa z semantem i kwalifikacjami - rofrol
Bardziej przypomina opinię i nie należy jej traktować jako ogólnie przyjętego podejścia. I ^ 0.1.x pobiera łaty idealnie w porządku. - ProLoser


~ : Rozsądnie blisko do

   ~1.1.5: 1.1.0 <= accepted < 1.2.0

^: Zgodny 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

42
2018-06-27 16:12



^0.1.3: 0.1.3 <= accepted < 1.0.0 zamiast tego, nie? - kytwb
@kytwb - nie. W szczególnym przypadku numerów wersji zeroth-release karat jest odpowiednikiem tyldy. A zatem ^0.1.3 akceptuje tylko wersje 0.1.x i nie zaakceptuje 0.2.0, mimo że jest to niewielki przyrost. To zachowanie jest równoważne ~0.1.3. Rozumowanie tego zachowania wynika z faktu, że pakiety zeroth-release są nadal uważane za niestabilne; w słowach semver.org, # 4, "wszystko może się zmienić w każdej chwili" (w tym zmiany niezgodne z poprzednimi wersjami). - chharvey


Dopasowanie kapelusza można uznać za "zepsute", ponieważ nie będzie ono aktualizowane ^0.1.2 do 0.2.0. Gdy pojawi się oprogramowanie, użyj 0.x.y wersje i dopasowanie kapelusza będą pasowały tylko do ostatniej zmieniającej się cyfry (y). Dokonuje się tego celowo. Powodem jest to, że podczas gdy oprogramowanie ewoluuje, API szybko się zmienia: pewnego dnia masz te metody, a kiedy indziej masz te metody, a stare już nie. Jeśli nie chcesz łamać kodu dla osób, które już korzystają z Twojej biblioteki, możesz przejść do większej wersji głównej: np. 1.0.0 -> 2.0.0 -> 3.0.0. Tak więc, zanim twoje oprogramowanie zostanie w 100% wykonane i będzie w pełni funkcjonalne, będzie ono wyglądało jak wersja 11.0.0 i to nie wygląda zbyt znacząco, a właściwie wygląda na zagmatwane. Jeśli natomiast używasz 0.1.x -> 0.2.x -> 0.3.x wtedy wersje oprogramowania są w 100% zrobione iw pełni funkcjonalne są wydawane w wersji 1.0.0 i oznacza to "Ta wersja jest usługą długoterminową, możesz kontynuować i korzystać z tej wersji biblioteki w swoim kodzie produkcyjnym, a autor nie zmieni wszystkiego jutro lub w przyszłym miesiącu, a on nie porzuci pakiet".

Zasada brzmi: użyj 0.x.y wersjonowanie, gdy Twoje oprogramowanie jeszcze nie dojrzało i wypuść je z inkrementacją środkowej cyfry, gdy zmienia się publiczny interfejs API (dlatego osoby mające ^0.1.0 nie dostanie 0.2.0 aktualizacja i nie złamie ich kodu). Następnie, gdy oprogramowanie dojrzeje, zwolnij je pod 1.0.0 i zwiększaj najbardziej wysuniętą na lewo cyfrę za każdym razem, gdy zmienia się publiczny interfejs API (w związku z czym osoby posiadające ^1.0.0 nie dostanie 2.0.0 aktualizacja 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.

21
2017-10-19 11:24



Ten komentarz był niedorzecznie 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: znalazłem te informacje również przez Google'a i grę z kalkulatorem npm semantic semver.npmjs.com - asdfasdfads
Musi być dodany do ich dokumentacji w bardziej formalny sposób. Rozmawiałem w Sony z moją ekipą inżynierską, ponieważ wydaje się, że tak łatwo można ją przeoczyć. slides.com/proloser/semver-v0 - ProLoser


^ jest 1. [dowolny]. [dowolny] (najnowsza wersja drugorzędna)
~ jest 1.2. [dowolny] (najnowszy patch)

Świetna lektura to ten wpis na blogu o tym, jak semver ma zastosowanie do npm
i co robią, aby to pasowało standard semantyczny
http://blog.npmjs.org/post/98131109725/npm-2-0-0


20
2017-12-15 18:07



not true: Caret Ranges ^ 1.2.3 ^ 0.2.5 ^ 0.0.4. Pozwala na zmiany, które nie modyfikują lewej, niezerowej cyfry w krotce [dur, minor, patch]. Innymi słowy, pozwala to na aktualizację łatek i mniejszych wersji dla wersji 1.0.0 i nowszych, aktualizacje łat dla wersji 0.X> = 0.1.0 oraz aktualizacje dla wersji 0.0.X. docs.npmjs.com/misc/semver#caret-ranges-1-2-3-0-2-5-0-0-4 - rofrol


Jedno wyjaśnienie dotyczące wykładziny

Standardowy system wersjonowania to major.minor.build (na przykład 2.4.1)

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

~ : wersja główna jest poprawiona, poprawiona wersja minorowa, pasuje do dowolnego numeru kompilacji

na przykład : ~ 2.4.1 oznacza, że ​​sprawdzi 2.4.x gdzie x jest cokolwiek

^ : wersja główna jest poprawiona, pasuje do dowolnej wersji drugorzędnej, pasuje do dowolnego numeru kompilacji

na przykład : ^ 2.4.1 oznacza, że ​​sprawdzi, czy 2.x.x gdzie x jest cokolwiek


8
2018-01-21 08:00



Widzę 7 linii w tej odpowiedzi - FluxLemur


~ Tilde:

  • ~ poprawki liczby główne i drugorzędne.
  • Jest używany, gdy jesteś gotowy, aby zaakceptować poprawki błędów w zależności, ale nie chcę żadnych potencjalnie niezgodnych zmian.
  • Tilda pasuje do najnowsza wersja drugorzędna (środkowy numer).
  • ~ 1.2.3 będzie pasować do wszystkich wersji 1.2.x, ale będzie brakowało 1.3.0.
  • Tilde (~) daje aktualizacje błędów

^ Caret:

  • ^ naprawia tylko główną liczbę.
  • Jest używany, gdy uważnie przyglądasz się zależnościom i jesteś gotowy na szybką zmianę kodu, jeśli niewielkie wydanie będzie niezgodne.
  • To zaktualizuje cię do najnowsza główna wersja (pierwszy numer).
  • ^ 1.2.3 będzie pasować do każdego wydania 1.x.x, w tym 1.3.0, ale zatrzyma się na 2.0.0.
  • Caret (^) zapewnia również kompatybilność wsteczną z nowymi funkcjami.

3
2017-09-30 10:56



Tilde pasuje do najnowszej wersji poprawki (ostatniego numeru). Daszek pasuje do najnowszej wersji pomniejszej (środkowej). - Abdul Rauf