Testez des versions face à une plage npm comme ^1.2.3, triez-les et voyez la version suivante
Fonctionne dans votre navigateur. Rien de ce que vous saisissez n'est envoyé nulle part. Vérifié le 16 octobre 2026.Une plage semver indique les versions qu'un paquet accepte. Dans npm, ^1.2.3 signifie au moins 1.2.3 et en dessous de 2.0.0, tandis que ~1.2.3 s'arrête en dessous de 1.3.0. En dessous de la version 1, l'accent circonflexe est plus strict, donc ^0.2.3 s'arrête en dessous de 0.3.0. Une préversion comme 1.3.0-beta ne correspond qu'à une plage qui nomme une préversion de 1.3.0.
Cette page a été traduite automatiquement à partir de l'original anglais. Aucune personne n’a encore relu la traduction : c’est la version anglaise qui fait foi. Lire l'original en anglais
Saisissez la plage issue de package.json, comme ^1.2.3 ou >=18 <21, dans le champ Plage.
Collez les versions à tester, une par ligne, ou cliquez sur Essayer un exemple.
Lisez la liste : chaque version est marquée comme correspondante ou non, triée de la plus basse à la plus haute, avec la correspondance la plus haute indiquée.
Cliquez sur Copier pour récupérer la liste triée, ou sur Copier les correspondances pour les seules versions dans la plage.
Semantic Versioning écrit une version sous la forme MAJOR.MINOR.PATCH : un changement majeur peut casser le code qui l'utilise, un changement mineur ajoute des fonctionnalités et un correctif ne fait que corriger des bogues. Les gestionnaires de paquets s'appuient sur cette promesse lorsqu'ils lisent une plage comme ^1.2.3 dans package.json et choisissent la version la plus récente qui convient.
Saisissez une plage et collez des versions, une par ligne. Chaque version est marquée comme dans la plage ou hors de la plage, la liste est triée dans le véritable ordre des versions, et les correspondances la plus haute et la plus basse sont indiquées. La plage est aussi écrite sous forme de comparateurs simples, exactement comme npm l'affiche, donc ^0.2.3 apparaît comme >=0.2.3 <0.3.0-0.
| Plage | Signifie | Exemple correspondant |
|---|---|---|
^1.2.3 |
>=1.2.3 <2.0.0 | 1.9.4 |
^0.2.3 |
>=0.2.3 <0.3.0 | 0.2.9 |
~1.2.3 |
>=1.2.3 <1.3.0 | 1.2.10 |
1.x |
>=1.0.0 <2.0.0 | 1.4.0 |
1.2.3 - 2.3 |
>=1.2.3 <2.4.0 | 2.3.9 |
>=18 <21 |
de 18.0.0 jusqu'en dessous de 21.0.0 | 20.11.1 |
Ordre. Les nombres sont comparés en tant que nombres, donc 1.10.0 est plus récente que 1.9.0. Une préversion se classe en dessous de sa version finale : 2.0.0-rc.1 vient avant 2.0.0. Dans une préversion, les parties numériques sont comparées numériquement et classées avant les mots, donc beta.2 est en dessous de beta.11 et 1 en dessous de alpha. Les métadonnées de build après un signe plus ne changent jamais l'ordre.
Erreurs expliquées. Une ligne qui n'est pas une version indique pourquoi : il manque à 1.2 son numéro de correctif, 01.2.3 a un zéro initial et 1.2.3.4 a une partie de trop. Lorsque la correction est évidente, elle est proposée.
Versions suivantes. Pour la version la plus haute de la liste, les versions majeure, mineure, de correctif et préversion suivantes sont affichées, telles que npm version les écrirait.
Chaque réponse est vérifiée par rapport à node-semver, la bibliothèque qu'utilise npm lui-même, sur plus de 3 000 comparaisons et 100 plages. Tout s'exécute dans votre navigateur ; rien de ce que vous collez n'est envoyé nulle part.
Un tilde n'autorise que les mises à jour de correctif : ~1.2.3 accepte 1.2.4 et 1.2.10 mais pas 1.3.0. Un accent circonflexe autorise aussi les mises à jour mineures : ^1.2.3 accepte tout ce qui est en dessous de 2.0.0. Comme npm écrit un accent circonflexe par défaut, la plupart des projets reçoivent automatiquement les nouvelles fonctionnalités et ne s'arrêtent qu'à la version majeure suivante.
En dessous de 1.0.0, npm traite le premier nombre non nul comme la version majeure, car l'API n'est pas encore stable. Ainsi, ^0.2.3 signifie au moins 0.2.3 et en dessous de 0.3.0, et ^0.0.3 n'autorise que 0.0.3 elle-même. C'est le passage d'un paquet à 1.0.0 qui active la plage plus large de l'accent circonflexe.
Oui. Chaque partie d'une version sémantique est comparée comme un nombre entier, donc une version mineure de 10 est supérieure à 9. Trier les numéros de version comme du texte, ou les lire comme des décimales, place 1.10.0 avant 1.9.0, ce qui est faux. Collez les deux ici pour voir le bon ordre et la partie qui diffère.
Non. Une préversion ne correspond qu'à une plage qui nomme une préversion avec les mêmes numéros majeur, mineur et de correctif. Ainsi, 1.3.0-beta correspond à >=1.3.0-alpha mais pas à ^1.2.3, même si elle se classe à l'intérieur de cette plage. Les préversions restent exclues des installations normales, sauf si vous les demandez.
Une préversion vient avant sa version finale, donc 1.0.0-rc.1 est plus ancienne que 1.0.0. Les parties d'une préversion sont comparées une par une, séparées par des points : les nombres numériquement, les mots alphabétiquement, et les nombres avant les mots. L'ordre d'exemple de Semantic Versioning est alpha, alpha.1, alpha.beta, beta, beta.2, beta.11, rc.1, puis la version finale.
Tout ce qui suit un signe plus constitue des métadonnées de build, comme 1.0.0+20261016 ou 1.0.0+sha.5114f85. Les métadonnées de build identifient un build précis mais sont ignorées pour l'ordre, donc 1.0.0+a et 1.0.0+b comptent comme la même version. Les plages les ignorent aussi, et npm les supprime lorsqu'il affiche une plage.
Les taux et les règles changent ; vérifiez la source avant de vous fier à un chiffre.
Toujours bloqué ? Poser une question sur Vérificateur semver et toute personne qui connaît la réponse peut répondre. Aucun compte nécessaire.