Vai al contenuto

Verifica di intervalli semver

Semver Range Tester

Controlla quali versioni soddisfano un intervallo, confronta due versioni e ordina un elenco secondo la precedenza.

Risponde alle due domande che ci si pone davvero sul versionamento semantico: questa versione soddisfa questo intervallo, e quale di queste versioni installerebbe npm. Confronta anche due versioni per precedenza e mostra che cosa produrrebbe ogni salto di `npm version`.

🔒 Funziona interamente nel tuo browsersemverversionnpm

Intervallo

Comprende: 1.0.0 o successiva e precedente a 2.0.0

La grammatica degli intervalli di npm: `^` `~` `x` `-` `||` e gli operatori di confronto. Non fa parte di semver.org, che definisce solo il formato di una versione e il suo ordine.

Versioni

Una per riga, oppure separate da virgole.

Quali rientrano

Preversioni
  1. —1.0.0-alpha
  2. —1.0.0-alpha.1
  3. —1.0.0-alpha.beta
  4. —1.0.0-beta
  5. —1.0.0-beta.2
  6. —1.0.0-beta.11
  7. —1.0.0-rc.1
  8. rientra1.0.0
  9. rientra1.2.0verrebbe installata
  10. —2.0.0-rc.1
  11. —2.0.0
  12. —2.1.3

Confrontarne due

Ordine

1.0.0-beta.11 è maggiore

Differenza

prerelease

La precedenza segue alla lettera la clausola 11 di semver.org, metadati di build compresi — cioè ignorati.

Versione successiva

Ogni tipo di rilascio e la versione che produce.
major2.0.0
minor1.3.0
patch1.2.4
premajor2.0.0-alpha.0
preminor1.3.0-alpha.0
prepatch1.2.4-alpha.0
prerelease1.2.4-alpha.0

Quello che produrrebbe `npm version <tipo>`.

C’è una regola che sorprende tutti: una preversione rientra in un intervallo solo se l’intervallo stesso nomina una preversione dello stesso major.minor.patch. Ecco perché ^1.0.0 non corrisponde a 2.0.0-beta.1, ed ecco perché un tag rc non si installa mai da solo per sbaglio.

Come si usa

  1. Scrivere l’intervallo

    `^1.0.0`, `~1.2.3`, `>=1.2.7 <1.3.0`, `1.2.3 - 2.3.4` e `||` funzionano tutti. Sotto compare una descrizione in parole semplici di che cosa soddisfa.

  2. Incollare le versioni che si hanno

    Una per riga, oppure separate da virgole — l’uscita di `npm view <pkg> versions` si incolla così com’è. Ognuna viene marcata come corrispondente o no, e quella che installerebbe npm è etichettata.

  3. Confrontarne due, o pianificare la prossima release

    Il pannello di confronto segue esattamente la clausola 11 di semver.org. La tabella dei salti mostra che cosa produrrebbero `npm version major`, `preminor` e gli altri a partire da un dato punto di partenza.

Domande frequenti

Perché `^1.0.0` non soddisfa `2.0.0-beta.1`?

Due motivi insieme. `^1` non arriva mai al major 2, e per conto suo una prerelease soddisfa un intervallo solo quando l’intervallo stesso nomina una prerelease dello stesso major.minor.patch. È questa seconda regola che impedisce a un tag `rc` di installarsi per sbaglio.

Perché `^0.2.3` si comporta in modo diverso?

Sotto la 1.0.0 il caret si stringe al minor: `^0.2.3` ammette 0.2.x ma non 0.3.0, perché di un progetto 0.x si dà per scontato che rompa a ogni minor. È una regola di npm e non di semver.org, e sorprende tutti ogni volta.

`1.0.0+build.1` è diversa da `1.0.0`?

Stringhe diverse, stessa precedenza: la clausola 10 dice che i metadati di build vengono ignorati nel confronto. Il che vuol dire che un ordinamento su versioni che differiscono solo nei metadati di build non è stabile, e due versioni così non si possono ordinare affatto.

La sintassi degli intervalli fa parte di semver?

No. semver.org definisce il formato della versione e come si confrontano due versioni, e si ferma lì. `^`, `~`, `x` e `||` sono la grammatica degli intervalli di npm, che altri ecosistemi hanno preso in prestito oppure sostituito: Cargo, Composer e pip differiscono ciascuno nei dettagli.

Può ricevere da

Dopo

Questi accettano ciò che produce questo strumento, così il risultato può passare direttamente.