Saltar al contenido

Probador de rangos semver

Semver Range Tester

Comprueba qué versiones satisfacen un rango, compara dos versiones y ordena una lista por precedencia.

Responde a las dos preguntas que la gente tiene de verdad sobre el versionado semántico: ¿esta versión satisface este rango?, y ¿cuál de estas versiones instalaría npm? También compara dos versiones por precedencia y muestra qué produciría cada incremento de `npm version`.

🔒 Se ejecuta por completo en tu navegadorsemverversionnpm

Rango

Abarca: 1.0.0 o posterior y anterior a 2.0.0

La gramática de rangos de npm: `^` `~` `x` `-` `||` y los operadores de comparación. Esto no forma parte de semver.org, que solo define el formato de la versión y su orden.

Versiones

Una por línea, o separadas por comas.

Cuáles encajan

Preversiones
  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. encaja1.0.0
  9. encaja1.2.0se instalaría
  10. —2.0.0-rc.1
  11. —2.0.0
  12. —2.1.3

Comparar dos

Orden

1.0.0-beta.11 es mayor

Diferencia

prerelease

La precedencia sigue al pie de la letra la cláusula 11 de semver.org, metadatos de compilación incluidos, o sea, ignorados.

Siguiente versión

Cada tipo de publicación y la versión que produce.
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

Lo que produciría `npm version <tipo>`.

Hay una regla que sorprende a todo el mundo: una preversión entra en un rango solo cuando el propio rango menciona una preversión del mismo major.minor.patch. Por eso ^1.0.0 no coincide con 2.0.0-beta.1, y por eso una etiqueta rc nunca se instala sola por accidente.

Cómo se usa

  1. Escribe el rango

    `^1.0.0`, `~1.2.3`, `>=1.2.7 <1.3.0`, `1.2.3 - 2.3.4` y `||` funcionan todos. Debajo aparece una descripción en lenguaje llano de lo que coincide.

  2. Pega las versiones que tienes

    Una por línea, o separadas por comas: la salida de `npm view <pkg> versions` se pega directamente. Cada una se marca como coincidente o no, y la que npm instalaría lleva etiqueta.

  3. Compara dos, o planifica la próxima publicación

    El panel de comparación sigue exactamente la cláusula 11 de semver.org. La tabla de incrementos muestra qué producirían `npm version major`, `preminor` y los demás a partir de un punto de partida dado.

Preguntas frecuentes

¿Por qué `^1.0.0` no coincide con `2.0.0-beta.1`?

Por dos razones a la vez. `^1` nunca llega a la major 2, y por separado una preversión solo satisface un rango cuando el rango mismo nombra una preversión del mismo major.minor.patch. Esa segunda regla es la razón por la que una etiqueta `rc` nunca se instala sola por accidente.

¿Por qué `^0.2.3` se comporta distinto?

Por debajo de 1.0.0 el acento circunflejo se ciñe a la minor: `^0.2.3` permite 0.2.x pero no 0.3.0, porque se entiende que un proyecto 0.x rompe en cada minor. Es la regla de npm, no la de semver.org, y sorprende a la gente cada vez.

¿`1.0.0+build.1` es distinto de `1.0.0`?

Cadenas distintas, misma precedencia: la cláusula 10 dice que los metadatos de build se ignoran al comparar. Lo que significa que una ordenación sobre versiones que solo difieren en metadatos de build no es estable, y dos versiones así no pueden ordenarse en absoluto.

¿La sintaxis de rangos forma parte de semver?

No. semver.org define el formato de versión y cómo se comparan dos versiones, y ahí se detiene. `^`, `~`, `x` y `||` son la gramática de rangos de npm, que otros ecosistemas tomaron prestada o sustituyeron: Cargo, Composer y pip difieren cada uno en los detalles.

Puede recibir de

Después

Estas aceptan lo que produce esta herramienta, así que el resultado puede pasar directamente.