Prüfen Sie eine Version gegen einen SemVer-Bereich
Prüfen Sie in einem Schritt, ob eine Version in einen Bereich passt: 1.5.2 erfüllt >=1.0.0 <2.0.0, 1.5.0-beta.1 dagegen nicht, weil ein breiter Bereich nie versehentlich eine instabile Version zulässt. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Prüfen Sie eine Paketversion gegen einen semantischen Versionsbereich, ohne einen Paketmanager zu installieren oder Zeichenketten zu vergleichen. Diese Funktion validiert eine strikte Version nach Semantic Versioning 2.0.0, analysiert die angegebene Einschränkung und liefert unmittelbar wahr oder falsch zurück. Unterstützt werden exakte Versionen, Ungleichheitsoperatoren, Caret- und Tilde-Kompatibilität, durch Leerzeichen getrennte Schnittmengen sowie Alternativen mit einem doppelten senkrechten Strich. Fehlerhafte Versionen oder Bereichsausdrücke führen zu einem Eingabefehler. Damit eignet sich die Prüfung für Release-Werkzeuge, Abhängigkeitsanalysen, Bereitstellungsrichtlinien und interaktive Fehlerdiagnosen.
Wählen Sie die passende Bereichsform für Ihre Kompatibilitätsrichtlinie
Ein Bereich sollte beschreiben, welche Releases Ihre Software tatsächlich akzeptiert, und nicht lediglich wie eine Versionsangabe aussehen. Geben Sie eine vollständige semantische Version wie 1.4.7 ein und wählen Sie eine unterstützte Einschränkungsform. Ein exakter Bereich wie 1.4.7 akzeptiert nur dieselbe SemVer-Rangfolge.
Vergleichsoperatoren wie >=1.0.0, <2.0.0 und <=3.5.1 legen eindeutige Grenzen fest. Trennen Sie Vergleichsterme durch Leerzeichen, wenn alle erfüllt sein müssen, etwa bei >=1.0.0 <2.0.0. Mit einem doppelten senkrechten Strich erlauben Sie Alternativen, beispielsweise ^1.8.0 || ^2.2.0.
Build-Metadaten behandelt die Prüfung gemäß SemVer: Sie werden validiert, verändern jedoch nicht die Rangfolge. Eingaben müssen Haupt-, Neben- und Patchnummer enthalten. Verkürzte oder lockere Versionen werden deshalb abgelehnt und nicht mehrdeutig interpretiert.
Das zurückgegebene Feld satisfies ist ein boolescher Wert, der direkt in Bedingungen verwendet werden kann. Die Antwort wiederholt außerdem Version und Bereich, damit Protokolle und Oberflächen genau erkennen lassen, welche Richtlinie geprüft wurde.
Verstehen Sie Caret-, Tilde- und Vorabversionsregeln
Caret- und Tilde-Bereiche bilden zwei verbreitete Kompatibilitätsrichtlinien ab. Ein Caret-Bereich erlaubt normalerweise Änderungen, welche die erste von links ungleich null lautende Komponente nicht verändern. Daher akzeptiert ^1.2.3 Releases ab 1.2.3, jedoch nicht mehr 2.0.0.
Versionen mit der Hauptnummer null werden enger behandelt: ^0.2.3 endet vor 0.3.0 und ^0.0.3 vor 0.0.4. Ein Tilde-Bereich erlaubt Patchänderungen innerhalb der angegebenen Nebenversionslinie; ~1.2.3 beginnt somit bei 1.2.3 und endet vor 1.3.0. Vorabversionen erfordern besondere Aufmerksamkeit, weil ein allgemeiner Bereich nicht versehentlich instabile Builds zulassen sollte.
Eine Vorabversion kann eine Vergleichsgruppe nur erfüllen, wenn diese einen Vorabvergleich mit derselben Haupt-, Neben- und Patchnummer enthält. Beispielsweise kann 2.0.0-beta.2 den Bereich >=2.0.0-beta.1 <2.0.0 erfüllen, während 1.5.0-beta.1 nicht auf >=1.0.0 <2.0.0 passt. Dies entspricht dem vertrauten Sicherheitsverhalten von Paketmanagern und bewahrt zugleich die strikte SemVer-Rangfolge zwischen Vorabkennungen.
Diese Grenzen machen die gewünschte Stabilitätsrichtlinie deutlich.
Nutzen Sie deterministische Prüfungen in Release- und Abhängigkeitsabläufen
Diese Prüfung ist überall hilfreich, wo eine Versionsrichtlinie zu einer wiederholbaren Entscheidung werden muss. Ein Auftrag zur kontinuierlichen Integration kann vor Testbeginn bestätigen, dass die Laufzeitversion eine Paketanforderung erfüllt. Ein Bereitstellungsdienst kann ein Artefakt außerhalb einer genehmigten Release-Linie ablehnen.
Ein Abhängigkeitsbestand kann erfasste Versionen gegen ein Migrationsziel prüfen, während der Support ein strittiges Kompatibilitätsergebnis im Browser nachvollzieht. Die Implementierung stellt keine Netzwerkanfragen, liest keine Uhr und erzeugt keine Zufallswerte. Gleiche Eingaben liefern daher stets gleiche Ausgaben.
Numerische Versionsbestandteile werden als Ziffernfolgen und nicht als JavaScript-Zahlen verglichen, sodass Ergebnisse auch jenseits der sicheren Ganzzahlgrenze korrekt bleiben.
Anwendungsfälle
Laufzeitanforderungen durchsetzen
Prüfen Sie eine erkannte Laufzeit- oder Werkzeugversion gegen den unterstützten Bereich, bevor ein Build oder eine Bereitstellung fortgesetzt wird.
Paketkompatibilität untersuchen
Bewerten Sie installierte Abhängigkeitsversionen anhand deklarierter Richtlinien, ohne einen Paketmanager auszuführen.
Release-Auswahl diagnostizieren
Vollziehen Sie Caret-, Tilde-, Vergleichs- und Vorabversionsentscheidungen mit einem eindeutigen booleschen Ergebnis nach.
Häufige Fragen
Welche Bereichsoperatoren werden unterstützt?
Unterstützt werden exakte Versionen, <, <=, >, >=, =, Caret, Tilde, durch Leerzeichen getrennte UND-Terme und ODER-Alternativen mit doppeltem senkrechtem Strich.
Beeinflussen Build-Metadaten das Ergebnis?
Nein. Sie werden validiert, aber SemVer schließt sie von der Versionsrangfolge aus.
Warum scheitert eine Vorabversion an einem breiten Bereich?
Eine Vorabversion wird nur zugelassen, wenn ihre Vergleichsgruppe eine Vorabversion mit derselben Haupt-, Neben- und Patchnummer enthält.
Sind verkürzte Versionen oder Platzhalterbereiche zulässig?
Nein. Versionen benötigen Haupt-, Neben- und Patchkomponenten; nicht unterstützte lockere oder Platzhaltersyntax führt zu einem Eingabefehler.
Wie weit reicht ein Caret-Bereich wie ^1.2.3?
Von 1.2.3 bis ausschließlich 2.0.0. Bei einer Hauptversion null ist er enger: ^0.2.3 endet vor 0.3.0 und ^0.0.3 vor 0.0.4. Ein Tilde-Bereich wie ~1.2.3 endet vor 1.3.0.
Verwandte Tools
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/dev2/package-version-range-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"version":"1.5.2","range":">=1.0.0 <2.0.0"}'const res = await fetch("https://api.kit.forhosting.com/dev2/package-version-range-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"version": "1.5.2",
"range": ">=1.0.0 <2.0.0"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev2/package-version-range-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"version": "1.5.2",
"range": ">=1.0.0 <2.0.0"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/package-version-range-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"version":"1.5.2","range":">=1.0.0 <2.0.0"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"version":"1.5.2","range":">=1.0.0 <2.0.0"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/package-version-range-check", 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": "1.5.2",
"range": ">=1.0.0 <2.0.0"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev2.package_version_range_check",
"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.
Limits
max_chars_per_input | 2048 |
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. |
Technische Hinweise
Nutzen Sie deterministische Prüfungen in Release- und Abhängigkeitsabläufen
Eine ungültige Bereichssyntax erzeugt einen Fehler invalid_input und nicht das Ergebnis falsch. Diese Unterscheidung ist wesentlich: falsch bedeutet, dass eine gültige Richtlinie die Version abgelehnt hat; ein Fehler weist dagegen auf eine zu korrigierende Richtlinie hin. Verwenden Sie den interaktiven Ausführer für eine schnelle Prüfung oder rufen Sie die API für $0.002 auf, wenn die Entscheidung automatisiert werden soll.
Technische Fragen
Was geschieht bei einem fehlerhaften Bereich?
Die Funktion liefert einen Fehler invalid_input, statt die fehlerhafte Richtlinie als gültigen, nicht passenden Bereich zu behandeln.