Verifichi una versione in un intervallo SemVer
Verifichi in un passaggio se una versione rientra in un intervallo: 1.5.2 soddisfa >=1.0.0 <2.0.0, mentre 1.5.0-beta.1 no, perché un intervallo ampio non lascia mai passare per sbaglio una versione instabile. Gratis nel suo browser.
- Gratis
- Funziona nel suo browser
- Senza registrazione
- I suoi dati restano sul dispositivo
Esegui gratis nel browser
Verifichi una versione di pacchetto rispetto a un intervallo semantico senza installare un gestore di pacchetti né affidarsi al confronto tra stringhe. Questa capacità convalida una versione Semantic Versioning 2.0.0 rigorosa, analizza il vincolo indicato e restituisce direttamente vero o falso. Supporta versioni esatte, comparatori di disuguaglianza, compatibilità caret e tilde, intersezioni separate da spazi e alternative con doppia barra verticale. Versioni o espressioni malformate producono un errore di input, rendendo il controllo adatto a strumenti di rilascio, verifiche delle dipendenze, politiche di distribuzione e diagnosi interattive.
Scelga la forma di intervallo adatta alla Sua politica di compatibilità
Un intervallo deve descrivere le versioni realmente accettabili dal software, non limitarsi ad assomigliare a un’etichetta di versione. Inserisca una versione semantica completa, come 1.4.7, quindi scelga una delle forme di vincolo supportate. Un intervallo esatto come 1.4.7 accetta solo la stessa precedenza SemVer.
I comparatori >=1.0.0, <2.0.0 e <=3.5.1 stabiliscono limiti espliciti. Separi i termini con spazi per richiederli tutti, come in >=1.0.0 <2.0.0. Usi una doppia barra verticale per consentire più alternative, per esempio ^1.8.0 || ^2.2.0.
Il controllo gestisce i metadati di build secondo SemVer: li convalida, ma non cambia la precedenza. Gli input devono includere i numeri major, minor e patch; le versioni abbreviate o permissive vengono quindi rifiutate anziché interpretate in modo ambiguo. Il campo satisfies restituito è un booleano utilizzabile direttamente nelle condizioni.
La risposta ripete anche la versione e l’intervallo inviati, affinché registri e interfacce mostrino esattamente quale politica è stata valutata.
Comprenda il comportamento di caret, tilde e versioni preliminari
Gli intervalli caret e tilde esprimono due comuni politiche di compatibilità. Un intervallo caret normalmente consente modifiche che non alterano il componente diverso da zero più a sinistra. Pertanto ^1.2.3 accetta versioni da 1.2.3 fino a 2.0.0 esclusa.
Le versioni con major zero hanno limiti più stretti: ^0.2.3 termina prima di 0.3.0 e ^0.0.3 prima di 0.0.4. Un intervallo tilde consente variazioni patch nella linea minor indicata, quindi ~1.2.3 parte da 1.2.3 e termina prima di 1.3.0. Le versioni preliminari richiedono attenzione, perché un intervallo generale non dovrebbe ammettere per errore build instabili.
Una versione preliminare può soddisfare un insieme di comparatori soltanto se questo contiene un comparatore preliminare con lo stesso nucleo major, minor e patch. Per esempio, 2.0.0-beta.2 può corrispondere a >=2.0.0-beta.1 <2.0.0, mentre 1.5.0-beta.1 non corrisponde a >=1.0.0 <2.0.0. Questa regola conserva la sicurezza tipica dei gestori di pacchetti e la rigorosa precedenza SemVer tra identificatori preliminari.
I limiti rendono esplicita la stabilità desiderata.
Applichi controlli deterministici nei flussi di rilascio e dipendenza
Questo controllo è utile quando una politica di versione deve diventare una decisione ripetibile. Un’attività di integrazione continua può confermare che la versione dell’ambiente soddisfi il requisito di un pacchetto prima dell’avvio dei test. Un servizio di distribuzione può rifiutare un artefatto esterno a una linea di rilascio approvata.
Un inventario delle dipendenze può valutare le versioni registrate rispetto a un obiettivo di migrazione, mentre l’assistenza può riprodurre nel browser un risultato di compatibilità contestato. L’implementazione non effettua richieste di rete, non legge l’orologio e non genera valori casuali, quindi input identici producono sempre output identici. I componenti numerici vengono confrontati come stringhe di cifre anziché come numeri JavaScript, mantenendo risultati corretti oltre il limite degli interi sicuri.
La distinzione è importante: falso significa che una politica valida ha rifiutato la versione, mentre un errore indica che la politica va corretta.
Casi d'uso
Applichi i requisiti dell’ambiente
Verifichi una versione rilevata dell’ambiente o di uno strumento rispetto all’intervallo supportato prima di procedere con build o distribuzione.
Controlli la compatibilità dei pacchetti
Valuti le versioni delle dipendenze installate rispetto alle politiche dichiarate senza eseguire un gestore di pacchetti.
Analizzi la selezione dei rilasci
Riproduca decisioni caret, tilde, comparative e preliminari con un chiaro risultato booleano.
Domande frequenti
Quali operatori di intervallo sono supportati?
Sono supportati versioni esatte, <, <=, >, >=, =, caret, tilde, termini AND separati da spazi e alternative OR con doppia barra verticale.
I metadati di build influiscono sul risultato?
No. Vengono convalidati, ma SemVer li esclude dalla precedenza tra versioni.
Perché una versione preliminare non soddisfa un intervallo ampio?
Una versione preliminare è ammessa solo se l’insieme contiene un comparatore preliminare con lo stesso nucleo major, minor e patch.
Sono accettati versioni abbreviate o intervalli con caratteri jolly?
No. Le versioni devono contenere i componenti major, minor e patch; la sintassi permissiva o con caratteri jolly non supportata genera un errore.
Fin dove arriva un intervallo con accento circonflesso come ^1.2.3?
Da 1.2.3 fino a 2.0.0 esclusa. Con il numero principale uguale a zero è più stretto: ^0.2.3 si ferma prima di 0.3.0 e ^0.0.3 prima di 0.0.4. Un intervallo con tilde come ~1.2.3 si ferma prima di 1.3.0.
Strumenti correlati
Per sviluppatori — accesso via API
Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.
Endpoint
Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.
Chiamala dal tuo 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)Esempio di richiesta
{
"version": "1.5.2",
"range": ">=1.0.0 <2.0.0"
}Esempio di risposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev2.package_version_range_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.
Prezzi
Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.
Limiti
max_chars_per_input | 2048 |
Errori
| HTTP | Codice | Significato |
|---|---|---|
401 | unauthorized | Chiave API mancante o non valida: controlla l'header Authorization. |
402 | insufficient_balance | Credito esaurito: ricarica per continuare a eseguire attività. |
404 | unknown_type | Tipo di attività sconosciuto: controlla il campo type della richiesta. |
429 | rate_limited | Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo. |
Note tecniche
Applichi controlli deterministici nei flussi di rilascio e dipendenza
Una sintassi di intervallo non valida produce un errore invalid_input, non un risultato falso. Usi l’esecutore interattivo per un controllo rapido o chiami l’API per $0.002 quando la decisione fa parte di un’automazione.
Domande tecniche
Che cosa accade se l’intervallo è malformato?
La capacità restituisce un errore invalid_input invece di considerare la politica malformata un intervallo valido senza corrispondenza.