Zum Inhalt springen

Semver-Bereichstester

Semver Range Tester

Prüft, welche Versionen einen Bereich erfüllen, vergleicht zwei Versionen und sortiert eine Liste nach Vorrang.

Beantwortet die zwei Fragen, die man bei semantischer Versionierung tatsächlich hat: Erfüllt diese Version diesen Bereich, und welche dieser Versionen würde npm installieren. Es vergleicht auch zwei Versionen nach Rangfolge und zeigt, was jeder `npm version`-Sprung ergeben würde.

🔒 Läuft vollständig in Ihrem Browsersemverversionnpm

Bereich

Umfasst: 1.0.0 oder neuer und älter als 2.0.0

Die Bereichsgrammatik von npm: `^` `~` `x` `-` `||` und die Vergleichsoperatoren. Sie gehört nicht zu semver.org, das nur das Format einer Version und deren Reihenfolge festlegt.

Versionen

Eine pro Zeile oder durch Kommas getrennt.

Welche passen

Vorabversionen
  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. passt1.0.0
  9. passt1.2.0würde installiert
  10. —2.0.0-rc.1
  11. —2.0.0
  12. —2.1.3

Zwei vergleichen

Reihenfolge

1.0.0-beta.11 ist höher

Unterschied

prerelease

Die Reihenfolge folgt genau Klausel 11 von semver.org, Build-Metadaten eingeschlossen — also ignoriert.

Nächste Version

Jede Release-Art und die Version, die sie erzeugt.
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

Was `npm version <Typ>` erzeugen würde.

Eine Regel überrascht alle: Eine Vorabversion erfüllt einen Bereich nur dann, wenn der Bereich selbst eine Vorabversion desselben major.minor.patch nennt. Deshalb passt ^1.0.0 nicht auf 2.0.0-beta.1, und deshalb installiert sich ein Tag namens rc nie aus Versehen von selbst.

So funktioniert es

  1. Schreiben Sie den Bereich

    `^1.0.0`, `~1.2.3`, `>=1.2.7 <1.3.0`, `1.2.3 - 2.3.4` und `||` funktionieren alle. Eine Beschreibung in Klartext, was er abdeckt, erscheint darunter.

  2. Fügen Sie die Versionen ein, die Sie haben

    Eine pro Zeile oder kommagetrennt – die Ausgabe von `npm view <pkg> versions` lässt sich direkt einfügen. Jede wird als passend oder nicht passend markiert, und die, die npm installieren würde, ist beschriftet.

  3. Vergleichen Sie zwei, oder planen Sie die nächste Version

    Das Vergleichs-Panel folgt exakt Klausel 11 von semver.org. Die Sprungtabelle zeigt, was `npm version major`, `preminor` und die übrigen von einem gegebenen Ausgangspunkt aus ergeben würden.

Häufige Fragen

Warum passt `^1.0.0` nicht zu `2.0.0-beta.1`?

Aus zwei Gründen zugleich. `^1` erreicht nie Major 2, und davon unabhängig erfüllt ein Prerelease einen Bereich nur, wenn der Bereich selbst ein Prerelease desselben major.minor.patch nennt. Diese zweite Regel ist der Grund, warum ein `rc`-Tag sich nie aus Versehen selbst installiert.

Warum verhält sich `^0.2.3` anders?

Unter 1.0.0 zieht sich das Caret auf das Minor zusammen: `^0.2.3` erlaubt 0.2.x, aber nicht 0.3.0, weil ein 0.x-Projekt als eines gilt, das bei jedem Minor bricht. Es ist npms Regel, nicht die von semver.org, und sie überrascht jedes Mal.

Ist `1.0.0+build.1` etwas anderes als `1.0.0`?

Verschiedene Strings, gleiche Rangfolge – Klausel 10 sagt, Build-Metadaten werden beim Vergleichen ignoriert. Das heißt, eine Sortierung über Versionen, die sich nur in den Build-Metadaten unterscheiden, ist nicht stabil, und zwei solche Versionen lassen sich überhaupt nicht ordnen.

Ist die Bereichssyntax Teil von semver?

Nein. semver.org definiert das Versionsformat und wie zwei Versionen sich vergleichen, und hört dort auf. `^`, `~`, `x` und `||` sind npms Bereichsgrammatik, die andere Ökosysteme entweder übernommen oder ersetzt haben – Cargo, Composer und pip unterscheiden sich jeweils in den Details.

Eingabe aus

Danach

Diese Tools nehmen an, was dieses hier erzeugt, das Ergebnis kann also direkt weiter.