Quelle est la différence entre tilde (~) et caret (^) dans package.json?

Dans les termes les plus simples, le tilde correspond à la version mineure la plus récente (le nombre du milieu). ~ 1.2.3 correspond à toutes les versions 1.2.x mais ne manquera pas 1.3.0.

Le caret, en revanche, est plus détendu. Il vous actualisera à la version majeure la plus récente (le premier numéro). ^ 1.2.3 correspond à toute version 1.xx incluant 1.3.0, mais sera bloqué sur 2.0.0.

http://fredkschott.com/post/2014/02/npm-no-longer-defaults-to-tildes/

J'aimerais ajouter la documentation officielle npmjs qui décrit toutes les méthodes de spécificité de la version, y compris celles mentionnées dans la question –

https://www.npmjs.org/doc/files/package.json.html

https://docs.npmjs.com/misc/semver#x-ranges-12x-1x-12-

• ~version "approximativement équivalente à la version" Voir npm semver – Tilde Ranges & semver (7)
• ^version "Compatible avec la version" Voir npm semver – Caret Ranges & semver (7)
• version doit correspondre exactement à la version
• >version doit être supérieure à la version
• >=version etc
• <version
• <=version
• 1.2.x 1.2.0, 1.2.1, etc., mais pas 1.3.0
• http://sometarballurl (peut-être l'URL d'un tarball qui sera téléchargé et installé localement
• * Correspond à n'importe quelle version
• latest Obtient la dernière version

La liste ci-dessus n'est pas exhaustive. Les autres spécificateurs de version incluent les URL de GitHub et les références d'utilisateurs de GitHub, les chemins d'accès locaux et les packages avec des balises npm spécifiques

Npm permet d'installer une version plus récente d'un paquetage que celle spécifiée. L'utilisation de tilde (~) vous permet de supprimer les corrections de bogues et le caret (^) vous offre également de nouvelles fonctionnalités compatibles avec l'arrière.

Le problème est que les anciennes versions ne reçoivent généralement pas de corrections de bogues, donc npm utilise le caret (^) comme valeur par défaut pour --save .

Selon: "Semver a expliqué, pourquoi il y a un caret (^) dans mon package.json?" .

Notez que les règles s'appliquent aux versions supérieures à 1.0.0 et que tous les projets ne suivent pas le versionnement sémantique.

Voici une explication visuelle des concepts:

Source: "Cheatsheet de versioning sémantique" .

~ Fixe les nombres majeurs et mineurs. Il est utilisé lorsque vous êtes prêt à accepter des corrections de bogues dans votre dépendance, mais ne voulez pas de modifications potentiellement incompatibles.

^ Fixe le numéro principal seulement. Il est utilisé lorsque vous surveillez attentivement vos dépendances et êtes prêt à changer rapidement votre code si une version mineure sera incompatible.

En plus de cela, ^ n'est pas pris en charge par les anciennes versions de npm, et devrait être utilisé avec prudence.

Donc, ^ est un bon défaut, mais ce n'est pas parfait. Je suggère de choisir et de configurer avec soin l'opérateur Semver qui vous convient le mieux.

Semver

 <major>.<minor>.<patch>-beta.<beta> == 1.2.3-beta.2 

• Utilisez la calculatrice npm semver pour tester. (Bien que les explications pour ^ (inclure tout ce qui est supérieur à une version particulière dans la même gamme majeure) et ~ (inclure tout ce qui est supérieur à une version particulière dans la même gamme mineure) ne sont pas 100% correctes, la calculatrice semble fonctionner bien )
• Alternativement, utilisez SemVer Check à la place, ce qui ne vous oblige pas à choisir un package et vous propose également des explications.

Version Pin ou autoriser les mises à jour

Vous pouvez définir une version comme 1.2.3 ou autoriser des mises à jour sur le:

• Deuxième niveau non nul de la gauche en utilisant ^ : ^0.2.3 signifie 0.2.3 <= v < 0.3 .
• Dernier niveau non nul de la droite en utilisant ~ (allez vers la gauche jusqu'à ce que vous trouviez non nul, si vous ne pouvez pas – définir le sous-niveau à 0): ~0 signifie 0.0 <= v < 1 .
• ~ Permet de modifier le niveau de patch si une version mineure est spécifiée sur le comparateur. Permet des changements de niveau mineur, sinon. ~1.2.4 signifie 1.2.4 <= v < 1.3.0 . ~1.2 signifie 1.2.0 <= v < 1.3.0 . ~1 signifie 1.0.0 <= v < 2.0.0
• Le niveau le plus juste par niveau de médiage: 0.2 signifie 0.2 <= v < 1 . Diffère de ~ parce que:
  • La version de début de niveau est toujours 0
  • Vous pouvez définir la version principale de départ sans spécifier les sous-niveaux.

Toutes les possibilités (espérons-le)

Définir le niveau principal et permettre les mises à jour vers le haut

 * or "" (empty string) any version 1 v >= 1 

Congéler le niveau principal

 ~0 (0) 0.0 <= v < 1 0.2 0.2 <= v < 1 // Can't do that with ^ or ~ ~1 (1, ^1) 1 <= v < 2 ^1.2 1.2 <= v < 2 ^1.2.3 1.2.3 <= v < 2 ^1.2.3-beta.4 1.2.3-beta.4 <= v < 2 

Gel de niveau mineur

 ^0.0 (0.0) 0 <= v < 0.1 ~0.2 0.2 <= v < 0.3 ~1.2 1.2 <= v < 1.3 ~0.2.3 (^0.2.3) 0.2.3 <= v < 0.3 ~1.2.3 1.2.3 <= v < 1.3 

Congéler le niveau du patch

 ~1.2.3-beta.4 1.2.3-beta.4 <= v < 1.2.4 (only beta or pr allowed) ^0.0.3-beta 0.0.3-beta.0 <= v < 0.0.4 or 0.0.3-pr.0 <= v < 0.0.4 (only beta or pr allowed) ^0.0.3-beta.4 0.0.3-beta.4 <= v < 0.0.4 or 0.0.3-pr.4 <= v < 0.0.4 (only beta or pr allowed) 

Interdire les mises à jour

 1.2.3 1.2.3 ^0.0.3 (0.0.3) 0.0.3 

Avis : Le majeur, le mineur, le patch ou la spécification beta sans numéro sont les mêmes que pour le niveau manquant.

Remarque : Lorsque vous installez pakckage dont 0 est le niveau principal, la mise à jour n'installera que la nouvelle version de niveau beta / pr! C'est parce que npm définit ^ comme défaut dans package.json et lorsque la version installée est comme 0.1.3 , elle gèle tous les niveaux principaux / mineurs / correctifs.

• https://docs.npmjs.com/misc/semver
• https://docs.npmjs.com/files/package.json#dependencies

~ : Raisonnablement proche de

  ~1.1.5: 1.1.0 <= accepted < 1.2.0 

^ : Compatible avec

  ^1.1.5: 1.1.5 <= accepted < 2.0.0 ^0.1.3: 0.1.3 <= accepted < 0.2.0 ^0.0.4: 0.0.4 <= accepted < 0.1.0 

^ Est 1. [any]. [Any] (dernière version mineure)
~ Est 1.2. [Any] (dernier patch)

Une excellente lecture est cette publication de blog sur la façon dont Semver s'applique à npm
Et ce qu'ils font pour le faire correspondre à la norme Semver
http://blog.npmjs.org/post/98131109725/npm-2-0-0

L'appariement des chapeaux peut être considéré comme "cassé" car il ne ^0.1.2 pas à jour ^0.1.2 à ^0.1.2 . Lorsque le logiciel est en train d'émerger, utilisez les versions de 0.xy et l'appariement des chapeaux qui ne correspondent que au dernier chiffre variable ( y ). C'est fait exprès. La raison en est que pendant que le logiciel évolue, l'API change rapidement: un jour, vous avez ces méthodes et l'autre jour, vous avez ces méthodes et les anciennes disparues. Si vous ne voulez pas casser le code pour les personnes qui utilisent déjà votre bibliothèque, allez et augmentez la version majeure: par ex. 1.0.0 -> 2.0.0 -> 3.0.0 . Donc, au moment où votre logiciel est finalement réalisé à 100% et complet, il sera comme la version 11.0.0 et cela ne semble pas très significatif et semble confus. Si vous étiez, en revanche, en utilisant les 0.1.x -> 0.2.x -> 0.3.x puis, au moment où le logiciel est finalement réalisé à 100%, il est publié en version 1.0.0 et signifie "Cette version est un service à long terme, vous pouvez procéder et utiliser cette version de la bibliothèque dans votre code de production, et l'auteur ne changera pas tout demain ou le mois prochain, et il n'abandonnera pas le paquet".

La règle est la suivante: utilisez la 0.xy version 0.xy lorsque votre logiciel n'a pas encore mûri et relâchez-le en incrémentant le chiffre du milieu lorsque votre API publique change (par conséquent, les personnes ayant ^0.1.0 n'obtiendront aucune mise à jour 0.2.0 et gagneront ' T briser leur code). Ensuite, lorsque le logiciel arrive à maturité, 1.0.0 sous 1.0.0 et incrémentez le chiffre le plus à gauche chaque fois que votre API publique change (les personnes ayant ^1.0.0 n'obtiendront pas 2.0.0 jour et ne rompront pas leur code).

 Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. 

Une explication de ligne

Le système de version standard est major.minor.build (par ex. 2.4.1)

Npm vérifie et corrige la version d'un paquet particulier en fonction de ces caractères

~ : La version majeure est corrigée, la version mineure est corrigée, correspond à n'importe quel numéro de construction

Par exemple: ~ 2.4.1 signifie qu'il vérifiera 2.4.x où x est n'importe quoi

^ : La version principale est corrigée, correspond à toute version mineure, correspond à n'importe quel numéro de construction

Par exemple: ^ 2.4.1 signifie qu'il vérifiera 2.xx où x est n'importe quoi

~ Tilde:

• ~ Fixe les nombres majeurs et mineurs.
• Il est utilisé lorsque vous êtes prêt à accepter des corrections de bogues dans votre dépendance, mais ne voulez pas de modifications potentiellement incompatibles.
• Le tilde correspond à la version mineure la plus récente (le nombre du milieu).
• ~ 1.2.3 correspond à toutes les versions 1.2.x, mais il manquera 1.3.0.
• Tilde (~) vous donne des corrections de bug

^ Caret:

• ^ Fixe le numéro principal seulement.
• Il est utilisé lorsque vous surveillez attentivement vos dépendances et êtes prêt à changer rapidement votre code si une version mineure sera incompatible.
• Il vous actualisera à la version majeure la plus récente (le premier numéro).
• ^ 1.2.3 correspond à toute version 1.xx incluant 1.3.0, mais elle sera bloquée sur 2.0.0.
• Caret (^) vous offre également de nouvelles fonctionnalités compatibles avec l'arrière.

^: Accepter la version change moins que Left Most Most-Zero Version (1er chiffre de version zéro à partir du côté gauche).

~: Accepter la version change moins de la deuxième version de la plupart des versions non zéro gauche (2ème chiffre de la version zéro à partir du côté gauche). OU S'il n'y a pas de deuxième version non-zéro gauche, alors la version Accept change moins que la version la plus à gauche.