SemVer-Bereich prüfen und Paketversionen testen
Paketaktualisierungen hängen oft von einer scheinbar kleinen Frage ab: Gehört eine bestimmte semantische Version zu dem Bereich, der in einem Manifest, einer Sperrdateiregel, einer Veröffentlichungsrichtlinie oder einer Kompatibilitätsmatrix steht?
Im Browser ausführen – kostenlos
Dieser Prüfer beantwortet sie mit der deterministischen Rangfolge von SemVer. Er versteht Vergleichsoperatoren, durch Leerzeichen verbundene Schnittmengen, Bindestrichbereiche, Platzhalter, Teilversionen und Alternativen mit doppeltem senkrechtem Strich. Vorabversions- und Build-Kennungen erhalten ihre korrekte semantische Bedeutung. Das Ergebnis eignet sich daher für Abhängigkeitswerkzeuge und ist keine grobe Zahlenannäherung.
Geben Sie eine Version und den zu prüfenden Bereich ein
Geben Sie eine vollständige semantische Version wie <code>2.4.1</code> und einen Bereichsausdruck an. In einer durch Leerzeichen getrennten Vergleichsgruppe müssen alle Bedingungen erfüllt sein; <code>>=2.0.0 <3.0.0</code> akzeptiert somit stabile Veröffentlichungen der Hauptversion zwei. Trennen Sie Gruppen mit <code>||</code>, wenn eine beliebige Alternative genügen darf. Auch eine exakte Version ist ein gültiger Bereich. Die Ausgabe enthält die normalisierte Version, den außen bereinigten Bereich, einen Wahrheitswert und die ab eins gezählte passende Alternative; null bedeutet, dass keine Alternative passt. Diese eindeutige Form lässt sich ohne Textauswertung in Bereitstellungssperren, Abhängigkeitsberichte, Manifesteditoren oder Tests einbauen. Eingaben bleiben Zeichenketten, weil eine Umwandlung ganzer Versionen in Gleitkommazahlen 1.10 fälschlich kleiner als 1.9 erscheinen ließe und Vorabinformationen verlöre. Ein führendes <code>v</code> wird bei vollständigen Versionen angenommen und bei der Normalisierung entfernt. Fehlerhafte Bestandteile, leere Alternativen und ungültige Kennungen führen zu einem typisierten Eingabefehler statt zu einem unzuverlässigen Falschwert.
Verwenden Sie Operatoren, Bindestriche und Platzhalter genau
Unterstützt werden <code>></code>, <code>>=</code>, <code><</code>, <code><=</code> und <code>=</code>. Mehrere Vergleiche in einer Alternative bilden eine Schnittmenge. Ein Ausdruck wie <code>1.2.3 - 2.4.0</code> schließt beide vollständigen Grenzen ein. Eine unvollständige Obergrenze wird bis zum Ende ihrer Komponentenfamilie erweitert: <code>1.2 - 2.4</code> beginnt bei 1.2.0 und endet vor 2.5.0. Platzhalter können als <code>x</code>, <code>X</code> oder <code>*</code> geschrieben werden. Daher umfasst <code>3.x</code> stabile Versionen von 3.0.0 bis vor 4.0.0; der Teilbereich <code>3.2</code> entspricht <code>3.2.x</code>. Platzhalter müssen auf bekannte Komponenten folgen. <code>1.x.4</code> wird abgelehnt, weil es kein zusammenhängendes Intervall beschreibt. Kurzformen mit Zirkumflex oder Tilde werden absichtlich nicht unterstützt. Schreiben Sie solche Grenzen mit ausdrücklichen Vergleichsoperatoren, damit die geprüfte Regel in Protokollen, erzeugten Richtlinien, automatischen Kontrollen und menschlichen Prüfungen sichtbar und eindeutig bleibt.
Verstehen Sie Rangfolge, Vorabversionen und Build-Metadaten
Semantische Versionen werden Bestandteil für Bestandteil und nicht alphabetisch verglichen. Zuerst entscheiden Haupt-, Neben- und Patchnummer. Eine Vorabversion steht vor der zugehörigen stabilen Veröffentlichung. Ihre durch Punkte getrennten Kennungen werden von links nach rechts verglichen: Zahlen numerisch, numerische Kennungen vor nichtnumerischen und ein kürzeres gleiches Präfix zuerst. Metadaten nach <code>+</code> bleiben in der normalisierten Ausgabe erhalten, ändern gemäß SemVer jedoch niemals die Rangfolge. Abhängigkeitsmanager schützen außerdem vor der unbeabsichtigten Auswahl von Vorabversionen. Dieser Prüfer folgt diesem Verhalten: Eine Vorabversion kann eine Gruppe nur erfüllen, wenn dieselbe Gruppe einen Vorabvergleich mit identischer Haupt-, Neben- und Patchnummer enthält. Beispielsweise kann <code>2.0.0-beta.2</code> den Bereich <code>>=2.0.0-beta.1 <2.0.0</code> erfüllen, gelangt aber nicht allein wegen des passenden Zahlenkerns in einen allgemeinen Platzhalterbereich. Jede Auswertung erfolgt lokal und deterministisch. Es werden weder Register abgefragt noch Pakete geladen oder aktuelle Veröffentlichungen geraten. Dieselben Zeichenketten liefern stets dieselbe Entscheidung.
Anwendungsfälle
Abhängigkeitskandidaten prüfen
Vergleichen Sie eine vorgeschlagene Paketversion mit dem Bereich des nutzenden Projekts, bevor Sie die Sperrdatei ändern.
Veröffentlichungsabläufe absichern
Erlauben oder verwerfen Sie Bereitstellungsartefakte anhand eines ausdrücklich festgelegten Kompatibilitätsfensters.
Manifestverhalten erklären
Testen Sie Grenzen, Platzhalter, Alternativen und Vorabversionen, um Entscheidungen eines Auflösers nachzuvollziehen.
Häufige Fragen
Was kostet eine Prüfung über die API?
Jede Anfrage kostet $0.002. Derselbe deterministische Prüfer kann auch direkt in Ihrem Browser ausgeführt werden.
Darf ein Bereich mehrere Bedingungen enthalten?
Ja. Trennen Sie UND-Bedingungen durch Leerzeichen und ODER-Alternativen durch ||.
Sind die Grenzen eines Bindestrichbereichs eingeschlossen?
Vollständige Grenzen sind eingeschlossen. Eine teilweise Obergrenze wird zur exklusiven Grenze oberhalb ihrer Familie.
Beeinflussen Build-Metadaten das Ergebnis?
Nein. Sie bleiben in der normalisierten Version erhalten, werden für die SemVer-Rangfolge aber ignoriert.
Warum scheitert eine Vorabversion an einem weiten Bereich?
Sie ist nur zulässig, wenn die Gruppe ausdrücklich eine Vorabversion mit denselben drei Kernnummern enthält.
Werden Bereiche mit Zirkumflex und Tilde unterstützt?
Nein. Verwenden Sie ausdrückliche Vergleiche, Bindestrichbereiche, Platzhalter, Teilversionen oder ||-Alternativen.
Für Entwickler — API-Zugang
Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.
Endpunkt
Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.
Aufruf aus Ihrem Stack
curl -X POST https://api.kit.forhosting.com/dev/semver-satisfies \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"version":"2.4.1","range":">=2.0.0 <3.0.0"}'const res = await fetch("https://api.kit.forhosting.com/dev/semver-satisfies", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"version": "2.4.1",
"range": ">=2.0.0 <3.0.0"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/semver-satisfies",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"version": "2.4.1",
"range": ">=2.0.0 <3.0.0"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/semver-satisfies", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"version":"2.4.1","range":">=2.0.0 <3.0.0"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"version":"2.4.1","range":">=2.0.0 <3.0.0"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/semver-satisfies", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"version": "2.4.1",
"range": ">=2.0.0 <3.0.0"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.semver_satisfies",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.
Preis
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
Fehler
| HTTP | Code | Bedeutung |
|---|---|---|
401 | unauthorized | Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer). |
402 | insufficient_balance | Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht. |
404 | unknown_type | Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog. |
429 | rate_limited | Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt. |