282 votes

Quelle est la syntaxe de version de bower (et npm) ?

Bower me permet de spécifier des exigences de version pour les paquets en utilisant la syntaxe suivante :

"dependencies": {
  "<name>": "<version>",
},

Mais je n'ai pas réussi à trouver la syntaxe à utiliser pour l'élément <version> . Je sais que je peux spécifier des versions à être :

  • supérieure à une certaine version avec ">1.0.0"
  • supérieur ou égal à une version : ">=1.0.0"
  • ou dans une certaine fourchette : "1.0.0 - 2.0.0" .

Je sais également qu'il existe une version commune de la syntaxe contenant le tilde : "~1.0.0" . Mais je ne suis pas sûr de ce que cela signifie et si c'est la même chose que "=1.0.0" .

Je souhaiterais également savoir si je peux spécifier plusieurs versions non consécutives, comme par exemple exactement 1.0.3 plus les versions supérieures à 1.5.0 etc.

3 votes

Il peut s'agir d'un doublon de stackoverflow.com/a/19040351/537738

342voto

XMLilley Points 2351

En bref, la syntaxe des numéros de version de Bower (et de NPM) est appelée SemVer, abréviation de "Semantic Versioning" (version sémantique). Vous trouverez de la documentation sur la syntaxe détaillée de SemVer telle qu'elle est utilisée dans Bower et NPM sur l'API de l'analyseur semver dans Node/npm . Vous pouvez en savoir plus sur la spécification sous-jacente (qui fait de la no mentionner ~ ou d'autres détails syntaxiques) à l'adresse semver.org .

Il y a un calculatrice visuelle super pratique pour les semences avec lesquels vous pouvez jouer, ce qui rend tout cela beaucoup plus facile à comprendre et à tester.

SemVer n'est pas qu'une syntaxe ! Il a des choses très intéressantes à dire sur les bonnes façons de publier des API, ce qui aidera à comprendre ce que signifie la syntaxe. C'est essentiel :

Une fois que vous avez identifié votre API publique, vous communiquez les modifications qui y sont apportées en ajoutant des incréments spécifiques à votre numéro de version. Considérer un format de version X.Y.Z (Major.Minor.Patch) . Les corrections de bogues n'affectant pas l'API incrémentent la version du correctif, les ajouts/modifications d'API rétrocompatibles incrémentent la version mineure, et les modifications d'API rétrocompatibles incrémentent la version majeure.

Ainsi, votre question spécifique sur ~ se rapporte à ce schéma Major.Minor.Patch. (Tout comme l'opérateur caret ^ .) Vous pouvez utiliser ~ pour réduire la gamme des versions que vous êtes prêt à accepter à l'une ou l'autre :

  • ultérieures niveau du correctif à la même version mineure ( "corrections de bogues n'affectant pas l'API" ), ou :
  • ultérieures niveau mineur à la même version majeure ( "ajouts/modifications de l'API compatibles avec la rétrocompatibilité". )

Par exemple : pour indiquer que vous prendrez tous les changements ultérieurs au niveau du patch sur l'arbre 1.2.x, à partir de 1.2.0, mais moins de 1.3.0, vous pourriez utiliser :

"angular": "~1.2"
  or:
"angular": "~1.2.0"

Vous obtiendrez également les mêmes résultats qu'en utilisant l'option .x syntaxe :

"angular": "1.2.x"

Mais vous pouvez utiliser le tilde/ ~ syntaxe pour être encore plus précis : si vous n'êtes prêt à accepter que des modifications au niveau du patch à partir de la version 1.2.4 mais toujours inférieur à 1.3.0, vous utiliserez :

"angular": "~1.2.4"

Vers la gauche, en direction de la majeur version, si vous utilisez...

"angular": "~1"

... c'est la même chose que...

"angular": "1.x"
  or:
"angular": "^1.0.0"

...et correspond à tous les changements mineurs ou au niveau des correctifs supérieurs à la version 1.0.0 et inférieurs à la version 2.0 :

Notez la dernière variation ci-dessus : il s'agit d'un Gamme de soins . Le caret ressemble beaucoup à un > On peut donc légitimement penser qu'il s'agit de "toute version". supérieur à 1.0.0". (J'ai certainement glissé sur ce point.) Non !

Les gammes de soins sont essentiellement utilisées pour dire que vous vous souciez des autres. sólo sur le chiffre significatif le plus à gauche - généralement la version majeure - et que vous autoriserez toute modification mineure ou au niveau du correctif qui n'affecte pas le chiffre le plus à gauche. Cependant, contrairement à un intervalle de tilde qui spécifie une version majeure, les intervalles de caret vous permettent de spécifier un point de départ mineur/patch précis. Ainsi, alors que ^1.0.0 === ~1 , une gamme de caret telle que ^1.2.3 vous permet de dire que vous accepterez tout changement >=1.2.3 && <2.0.0 . Il n'est pas possible de faire cela avec une plage de tilde.

Tout cela semble confus à première vue, quand on y regarde de plus près. Mais faites un zoom arrière pendant une seconde et réfléchissez-y de cette manière : le caret vous permet simplement de dire que vous vous intéressez plus particulièrement au chiffre significatif le plus à gauche. Le tilde permet de dire que l'on se préoccupe surtout du chiffre le plus à droite. Le reste n'est que détail.

C'est le pouvoir expressif du tilde et du caret qui explique pourquoi les gens les utilisent beaucoup plus que le plus simple .x syntaxe : ils vous permettent simplement d'en faire plus. C'est pourquoi vous verrez le tilde souvent utilisé même dans les cas où .x servirait. A titre d'exemple, voyez npm lui-même : son propre fichier package.json inclut de nombreuses dépendances en ~2.4.0 plutôt que le format 2.4.x le mettre en forme pourrait l'utilisation. En s'en tenant à ~ la syntaxe est cohérente tout au long d'une liste de plus de 70 dépendances versionnées, quel que soit le numéro de patch de départ acceptable.

Quoi qu'il en soit, SemVer ne s'arrête pas là, mais je n'essaierai pas de tout détailler ici. Jetez un coup d'œil sur le site readme du paquet node semver . Et veillez à utiliser le calculateur de version sémantique pendant que vous vous entraînez et que vous essayez de comprendre le fonctionnement de SemVer.


RE : Numéros de version non consécutifs : La dernière question de l'OP semble concerner la spécification de numéros de version/plages non consécutifs (si je l'ai bien formulée). Oui, vous pouvez le faire, en utilisant l'opérateur "ou" commun à deux tuyaux : || . Comme cela :

"angular": "1.2 <= 1.2.9 || >2.0.0"

27 votes

Donc ~ en particulier, le nombre de patchs (troisième) peut être supérieur à celui spécifié, par exemple. ~1.2.3 est équivalent à >=1.2.3 <1.3.0 .

1 votes

Peut également être utilisé pour le numéro mineur (deuxième), conformément aux modifications en ligne ci-dessus.

0 votes

Il est intéressant de noter que la documentation de SemVer semble également autoriser la notation x (qui est beaucoup plus intuitive pour les humains).

76voto

Wilfred Hughes Points 3507

Bower utilise syntaxe du sémaphore mais voici quelques exemples rapides :

Vous pouvez installer une version spécifique :

$ bower install jquery#1.11.1

Vous pouvez utiliser ~ pour spécifier "toute version commençant par ceci" :

$ bower install jquery#~1.11

Vous pouvez spécifier plusieurs exigences de version ensemble :

$ bower install "jquery#<2.0 >1.10"

1 votes

Je suis curieux d'en connaître l'utilisation pratique. Installation de la roulette ?

0 votes

En regardant la réponse de @XMLilley (et les documents de Semver), 'start's with' semble erroné, car 1.12, 1.13 seraient également acceptables, tant que, comme majo

13voto

shacker Points 3348

Vous pouvez également utiliser la fonction latest pour installer la version la plus récente disponible :

  "dependencies": {
    "fontawesome": "latest"
  }

7voto

Decima Points 116

S'il n'y a pas de numéro de patch, ~ équivaut à ajouter .x à la version non tilde. S'il existe un numéro de patch, ~ autorise tous les numéros de patchs >= au numéro spécifié.

~1     := 1.x
~1.2   := 1.2.x
~1.2.3 := (>=1.2.3 <1.3.0)

Je n'ai pas assez de points pour commenter la réponse acceptée, mais certaines informations sur le tilde sont en contradiction avec la documentation semver : "angular": "~1.2" volonté no match 1.3, 1.4, 1.4.9. En outre "angular": "~1" y "angular": "~1.0" sont no équivalent. Ceci peut être vérifié à l'aide de l'outil npm semver calculator .

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X