Saisissez une plage de package.json (^1.2.3, ~1.2.3, 1.x, >=1.0.0 <2.0.0, ||) et voyez exactement quelles versions elle accepte. Chargez la vraie liste des versions de n'importe quel paquet npm, ou collez la vôtre.
Essayez :
Se développe en
>=1.2.3 <2.0.0-0
au moins 1.2.3, en dessous de 2.0.0, aucune de ses pré-versions comprise
Version la plus haute acceptée : 1.9.9 · 4 versions acceptées sur 9
^ (caret) autorise tout changement qui ne modifie pas le premier chiffre non nul en partant de la gauche : ^1.2.3 vaut >=1.2.3 <2.0.0, mais ^0.2.3 vaut >=0.2.3 <0.3.0 et ^0.0.3 n'accepte que 0.0.3.
~ (tilde) autorise les correctifs quand une mineure est donnée : ~1.2.3 vaut >=1.2.3 <1.3.0. ~1 équivaut à 1.x.
x, X et * sont des jokers : 1.x vaut >=1.0.0 <2.0.0. Une partie absente compte comme un joker, donc 1.2 signifie 1.2.x.
Un espace signifie ET, || signifie OU. Une plage à trait d'union 1.2.3 - 2.3.4 inclut les deux bornes ; une borne haute partielle comme - 2.3 signifie en dessous de 2.4.0.
Les pré-versions (1.3.0-beta.1) sont exclues, sauf si la plage nomme elle-même une pré-version du même major.minor.patch. C'est la règle qui surprend le plus.
Logique écrite selon les règles de node-semver 7 utilisées par npm (mode strict, includePrerelease désactivé) et vérifiée contre le paquet semver avant publication. Les listes de versions viennent directement de registry.npmjs.org dans votre navigateur ; rien n'est envoyé à VersionDude.
Une plage flotte. Votre machine de build, non.
Un caret laisse la prochaine installation choisir une version plus récente ; seuls le lockfile et la machine qui lance npm ci rendent les builds reproductibles. Infomaniak, hébergeur suisse respectueux de la vie privée, propose des VPS et serveurs cloud pour faire tourner vos propres machines de build et d'intégration continue.