Compruebe una versión frente a un rango SemVer
Compruebe en un paso si una versión entra en un rango: 1.5.2 cumple >=1.0.0 <2.0.0, mientras que 1.5.0-beta.1 no, porque un rango amplio nunca deja pasar por accidente una versión inestable. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Compruebe una versión de paquete frente a un rango de versiones semánticas sin instalar un gestor de paquetes ni depender de comparaciones de texto. Esta capacidad valida una versión estricta de Semantic Versioning 2.0.0, analiza la restricción indicada y devuelve un resultado directo verdadero o falso. Admite versiones exactas, comparadores de desigualdad, compatibilidad caret y tilde, intersecciones separadas por espacios y alternativas con doble barra vertical. Las versiones y expresiones de rango mal formadas devuelven un error de entrada, por lo que el verificador resulta apropiado para herramientas de publicación, auditorías de dependencias, políticas de despliegue y diagnóstico interactivo.
Elija la forma de rango que exprese su política de compatibilidad
Un rango debe describir las versiones que su software puede aceptar realmente, no solo parecerse a una etiqueta de versión. Introduzca una versión semántica completa, como 1.4.7, y elija una de las formas de restricción admitidas. Un rango exacto como 1.4.7 solo acepta la misma precedencia SemVer.
Los comparadores, incluidos >=1.0.0, <2.0.0 y <=3.5.1, establecen límites explícitos. Separe los términos comparadores con espacios para exigir que todos se cumplan, como en >=1.0.0 <2.0.0. Use una doble barra vertical para permitir varias alternativas, por ejemplo ^1.8.0 || ^2.2.0.
El verificador trata los metadatos de compilación según SemVer: los valida, pero no modifican la precedencia. Las entradas deben incluir los números mayor, menor y de parche, de modo que las versiones abreviadas o flexibles se rechazan en vez de interpretarse de forma ambigua. El campo satisfies devuelto es un booleano preparado para condiciones directas, y la respuesta también repite la versión y el rango enviados para que los registros e interfaces muestren exactamente qué política se evaluó.
Comprenda el comportamiento de caret, tilde y las versiones preliminares
Los rangos caret y tilde codifican dos políticas de compatibilidad habituales. Un rango caret suele permitir cambios que no alteren el componente distinto de cero situado más a la izquierda. Por tanto, ^1.2.3 acepta versiones desde 1.2.3 hasta antes de 2.0.0.
Las versiones con mayor cero reciben un tratamiento más estrecho: ^0.2.3 termina antes de 0.3.0 y ^0.0.3 antes de 0.0.4. Un rango tilde permite cambios de parche dentro de la línea menor indicada, por lo que ~1.2.3 empieza en 1.2.3 y termina antes de 1.3.0. Las versiones preliminares exigen atención especial, ya que un rango general no debe admitir por accidente compilaciones inestables.
Una versión preliminar solo puede satisfacer un conjunto de comparadores cuando este contiene un comparador preliminar con el mismo núcleo mayor, menor y de parche. Por ejemplo, 2.0.0-beta.2 puede coincidir con >=2.0.0-beta.1 <2.0.0, pero 1.5.0-beta.1 no coincide con >=1.0.0 <2.0.0. Así se conserva el comportamiento seguro habitual de los gestores de paquetes y la precedencia SemVer estricta entre identificadores preliminares.
Estos límites hacen explícita la política de estabilidad deseada.
Aplique comprobaciones deterministas en flujos de publicación y dependencias
Este verificador resulta útil siempre que una política de versiones deba convertirse en una decisión repetible. Un trabajo de integración continua puede confirmar que la versión de ejecución cumple el requisito de un paquete antes de iniciar las pruebas. Un servicio de despliegue puede rechazar un artefacto situado fuera de una línea de versiones aprobada.
Un inventario de dependencias puede evaluar las versiones registradas frente a un objetivo de migración, mientras que el personal de soporte puede reproducir en el navegador un resultado de compatibilidad discutido. La implementación no realiza solicitudes de red, no consulta el reloj ni genera valores aleatorios, por lo que entradas idénticas siempre producen salidas idénticas. Los componentes numéricos se comparan como cadenas de dígitos en lugar de números de JavaScript, lo que conserva resultados correctos más allá del límite entero seguro.
Qué puede hacer con ella
Aplique requisitos del entorno de ejecución
Compruebe la versión detectada de un entorno o una herramienta frente al rango admitido antes de continuar una compilación o un despliegue.
Audite la compatibilidad de paquetes
Evalúe versiones de dependencias instaladas frente a políticas de compatibilidad declaradas sin ejecutar un gestor de paquetes.
Diagnostique la selección de versiones
Reproduzca decisiones de caret, tilde, comparadores y versiones preliminares con un resultado booleano claro.
Preguntas frecuentes
¿Qué operadores de rango se admiten?
Se admiten versiones exactas, <, <=, >, >=, =, caret, tilde, términos Y separados por espacios y alternativas O con doble barra vertical.
¿Los metadatos de compilación afectan al resultado?
No. Los metadatos de compilación se validan, pero SemVer los excluye de la precedencia entre versiones.
¿Por qué una versión preliminar no satisface un rango amplio?
Solo se admite una versión preliminar cuando su conjunto de comparadores incluye otra preliminar con el mismo núcleo mayor, menor y de parche.
¿Se aceptan versiones abreviadas o rangos con comodines?
No. Las versiones deben contener componentes mayor, menor y de parche; la sintaxis flexible o con comodines no admitida produce un error de entrada.
¿Hasta dónde llega un rango con acento circunflejo como ^1.2.3?
Desde 1.2.3 hasta 2.0.0, sin incluirla. Con un número mayor igual a cero es más estrecho: ^0.2.3 se detiene antes de 0.3.0 y ^0.0.3 antes de 0.0.4. Un rango con tilde como ~1.2.3 se detiene antes de 1.3.0.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su 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)Ejemplo de solicitud
{
"version": "1.5.2",
"range": ">=1.0.0 <2.0.0"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev2.package_version_range_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Límites
max_chars_per_input | 2048 |
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
Aplique comprobaciones deterministas en flujos de publicación y dependencias
Una sintaxis de rango inválida produce un error invalid_input y no un resultado falso; la diferencia importa porque falso significa que una política válida rechazó la versión, mientras que un error indica que debe corregirse la política. Use el ejecutor interactivo para una consulta rápida o llame a la API por $0.002 cuando la decisión forme parte de una automatización.
Preguntas técnicas
¿Qué ocurre si el rango está mal formado?
La capacidad devuelve un error invalid_input en vez de tratar una política mal formada como un rango válido que no coincide.