Domanda Qual è la differenza tra tilde (~) e caret (^) in package.json?


Dopo l'aggiornamento all'ultima versione stabile node e npm, Provai npm install moment --save. Salva la voce nel package.json con il caret(^) prefisso. In precedenza, era un tilde(~) prefisso.

  1. Perché sono fatti questi cambiamenti npm?
  2. Qual è la differenza tra tilde(~) e caret(^)?
  3. Quali sono i vantaggi rispetto agli altri?

2239
2018-03-12 06:02


origine


risposte:


Nei termini più semplici, la tilde corrisponde alla versione minore più recente   (il numero medio). ~ 1.2.3 corrisponderà a tutte le versioni 1.2.x ma lo farà   manca la 1.3.0.

Il cursore, d'altra parte, è più rilassato. Ti aggiornerà a   la versione principale più recente (il primo numero). ^ 1.2.3 corrisponderà   qualsiasi versione 1.x.x compresa la 1.3.0, ma rimarrà su 2.0.0.

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


2622
2018-03-12 08:28



Vorrei aggiungere anche la documentazione ufficiale di npmjs che descrive tutti i metodi per la specificità della versione, compresi quelli indicati nella domanda:

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

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

  • ~version "Approssimativamente equivalente alla versione" Vedi npm semver - Tilde Ranges & semere (7)
  • ^version "Compatibile con la versione" Vedi npm semiver - Caret Ranges & semere (7)
  • version Deve corrispondere esattamente alla versione
  • >version Deve essere maggiore della versione
  • >=version eccetera
  • <version
  • <=version
  • 1.2.x 1.2.0, 1.2.1, ecc., Ma non 1.3.0
  • http://sometarballurl (questo potrebbe essere l'URL di un tarball che verrà scaricato e installato localmente
  • * Corrisponde a qualsiasi versione
  • latest Ottiene l'ultima versione

L'elenco sopra non è esaustivo. Altri specificatori di versione includono URL GitHub e repository utente GitHub, percorsi locali e pacchetti con tag npm specifici


567
2017-09-16 06:25



Npm consente di installare una versione più recente di un pacchetto rispetto a quella specificata. Usando tilde (~) fornisce correzioni di bug e caret (^) offre anche nuove funzionalità compatibili con le versioni precedenti.

Il problema è che le vecchie versioni di solito non ricevono molte correzioni di bug, quindi npm usa il caret (^) come predefinito per --save.

semver table

Secondo: "Semver spiegato - perché c'è un accento circonflesso (^) nel mio package.json?".

Nota che le regole si applicano alle versioni sopra 1.0.0 e non tutti i progetti seguono il controllo delle versioni semantico. Per le versioni 0.x.x il segno di omissione consente solo toppa aggiornamenti, cioè si comporta come la tilde. Vedere "Gamme Ranges"

Ecco una spiegazione visiva dei concetti:

semver diagram

Fonte: "Cheatsheet di Version Semantic".


346
2017-07-30 20:40



~ corregge i numeri maggiori e minori. Viene utilizzato quando si è pronti ad accettare correzioni di errori nella dipendenza, ma non si desiderano eventuali modifiche potenzialmente incompatibili.

^ corregge solo il numero maggiore. Viene utilizzato quando si osservano da vicino le dipendenze e si è pronti a modificare rapidamente il codice se la versione secondaria non è compatibile.

In aggiunta a ciò, ^ è non supportato dalle vecchie versioni di npm e dovrebbe essere usato con cautela.

Così, ^ è un buon valore predefinito, ma non è perfetto. Suggerisco di scegliere con attenzione e configurare l'operatore semirigente più utile per te.


74
2018-03-12 23:05



Semver

<major>.<minor>.<patch>-beta.<beta> == 1.2.3-beta.2
  • Uso calcolatrice seminale npm per il test. (Sebbene le spiegazioni per ^ (includi tutto ciò che è maggiore di una particolare versione nello stesso intervallo maggiore) e ~ (includi tutto più grande di una particolare versione nello stesso intervallo minore) non sono corrette al 100%, la calcolatrice sembra funzionare bene )
  • In alternativa, usa Controllo SemVer invece, che non richiede di scegliere un pacchetto e offre anche spiegazioni.

Consentire o disabilitare le modifiche

  • Versione pin: 1.2.3.
  • Uso ^ (come la testa). Permette gli aggiornamenti al secondo livello non zero da sinistra: ^0.2.3 si intende 0.2.3 <= v < 0.3.
  • Uso ~ (come coda). Generalmente congela il livello più a destra o imposta zero se omesso:
    • ~1 si intende 1.0.0 <= v < 2.0.0
    • ~1.2 si intende 1.2.0 <= v < 1.3.0.
    • ~1.2.4 si intende 1.2.4 <= v < 1.3.0.
  • Ommit right-most level: 0.2 si intende 0.2 <= v < 1. Si differenzia da ~ perché:
    • L'avvio della versione a livello omesso è sempre 0
    • È possibile impostare l'avvio della versione principale senza specificare i sottolivelli.

Tutte le possibilità (si spera)

Imposta l'avvio di livello principale e consenti gli aggiornamenti verso l'alto

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

Congela livello principale

~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

Congela livello minore

^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

Blocca livello patch

~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)

Non consentire aggiornamenti

1.2.3             1.2.3
^0.0.3 (0.0.3)    0.0.3

Avviso: Mancante maggiore, minore, patch o specifica beta senza numero, è lo stesso di any per il livello mancante.

Avviso: Quando si installa un pacchetto che ha 0 come livello principale, l'aggiornamento installerà solo una nuova versione beta / pr! È perché npm imposta ^ come predefinito in package.json e quando è installata la versione 0.1.3, blocca tutti i livelli major / minor / patch.


66
2017-10-11 16:52



~ : Ragionevolmente vicino a

   ~1.1.5: 1.1.0 <= accepted < 1.2.0

^: Compatibile con

   ^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



La corrispondenza di Hat può essere considerata "interrotta" perché non si aggiorna ^0.1.2 a 0.2.0. Quando il software sta emergendo usa 0.x.y le versioni e la corrispondenza del cappello corrisponderanno solo all'ultima cifra variabile (y). Questo è fatto apposta. Il motivo è che mentre il software si evolve, l'API cambia rapidamente: un giorno hai questi metodi e l'altro giorno hai quei metodi e quelli vecchi sono spariti. Se non vuoi rompere il codice per le persone che già utilizzano la tua libreria, vai e incrementa la versione principale: ad es. 1.0.0 -> 2.0.0 -> 3.0.0. Quindi, quando il tuo software sarà finalmente realizzato al 100% e pieno di funzionalità, sarà come la versione 11.0.0 e questo non sembra molto significativo, e in realtà sembra confuso. Se tu fossi, d'altra parte, usando 0.1.x -> 0.2.x -> 0.3.x versioni quindi quando il software è finalmente completato al 100% e tutte le funzionalità sono rilasciate come versione 1.0.0 e significa "Questa versione è di servizio a lungo termine, puoi procedere e utilizzare questa versione della libreria nel tuo codice di produzione e l'autore non cambierà tutto domani o il mese prossimo e non abbandonerà il pacchetto".

La regola è: usare 0.x.y il controllo delle versioni quando il software non è ancora maturo e lo rilascia con l'incremento della cifra centrale quando le API pubbliche cambiano (quindi le persone hanno ^0.1.0 non otterrà 0.2.0 aggiornamento e non romperà il loro codice). Quindi, quando il software matura, rilasciarlo sotto 1.0.0 e incrementa la cifra più a sinistra ogni volta che la tua API pubblica cambia (quindi le persone hanno ^1.0.0 non otterrà 2.0.0 aggiornamento e non romperà il loro codice).

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



^ è 1. [any]. [any] (ultima versione minore)
~ è 1.2. [any] (ultima patch)

Una grande lettura è questo post del blog su come il semver si applica a npm
e cosa stanno facendo per farlo abbinare lo standard semere
http://blog.npmjs.org/post/98131109725/npm-2-0-0


20
2017-12-15 18:07