web-dev-qa-db-fra.com

Utiliser SNAPSHOT dans NPM privé comme dans Maven

J'ai une configuration de travail très simple:

Lib A                                             Lib B
publish 1.0.0-SNAPSHOT  ->  Private Registry  ->  npm install

Gardez à l'esprit que A et B sont sur des machines différentes (pensez au cluster jenkins!).

Pendant deux versions, les versions se terminent par "-SNAPSHOT" et sont mises à jour sur chaque build (A). Bien sûr, les bibliothèques dépendantes (B, ...) doivent toujours utiliser la dernière version du registre. Le problème est que NPM ne récupérera pas la même version.

Lib A                                           Lib B
small change, rebuild:
publish 1.0.0-SNAPSHOT  ->  Private Registry  !!  npm install -f
                                                  npm cache clean
                                              !!  npm install -f
                                                  rm -rf node_modules
                                              ->  npm install

Idée: désactiver le cache pour NPM globalement

Ce serait bien parce que nous avons un proxy npm local: "~/.npmrc":

force=true
cache-min=0
cache-max=0

Mais cela ne fonctionne pas! Seule la suppression du répertoire node_modules fonctionne. Ce n'est pas une solution utilisable car le développeur ne devrait pas avoir besoin d'utiliser "rm -rf node_modules && npm install".

Avec maven, cette configuration fonctionne car nous utilisons l'option "-U". Cela force maven à vérifier si une version SNAPSHOT mise à jour est disponible. NPM ne comprend pas le concept de SNAPSHOT mais devrait au moins demander le registre à chaque fois.

npm version 2.12.0

Registre privé: Sonatype Nexus ™ 2.10.0-02

mavennpmsnapshot
25
Tristan

Idée 1

Vous pouvez en quelque sorte imiter ce comportement si vous "abusez" de la partie de pré-version de SemVer. J'ai utilisé la stratégie suivante avec succès:

Publiez vos modules avec -SNAPSHOT mais ajoutez un nombre incrémenté chaque fois que vous publiez (-SNAPSHOT.# ou -SNAPSHOT-#).

Par exemple: "x.x.x-SNAPSHOT.1" la première publication, puis "x.x.x-SNAPSHOT.2" la deuxième publication et ainsi de suite.

Assurez-vous d'utiliser un modèle cohérent. Ainsi, par exemple, si vous avez utilisé des points, restez avec des points, ou si vous avez utilisé des tirets, restez avec des tirets.

Pour les modules dépendants, il vous suffit de déclarer votre version comme

"^x.x.x-SNAPSHOT"

et NPM récupérera la dernière version.

Tout cela fonctionne pour 2 raisons

  1. SemVer traite les versions préliminaires de la manière suivante 1.0.0-SNAPSHOT < 1.0.0-SNAPSHOT.1 < 1.0.0-SNAPSHOT.2 < 1.0.0-SNAPSHOT.3 ...
  2. NPM récupérera toujours la dernière version préliminaire

Avertissement: cela ne fonctionnera que pour les versions de patch. Techniquement, 1.2.x-SNAPSHOT est supérieur à 1.1.x-SNAPSHOT, cependant, SemVer n'en tient pas compte lors de l'utilisation de versions préliminaires.

De la documentation:

Si une version a une balise de pré-publication (par exemple, 1.2.3-alpha.3), elle ne sera autorisée à satisfaire les ensembles de comparateurs que si au moins un comparateur avec le même [majeur, mineur, patch] Tuple a également une balise de pré-publication .

Par exemple, la plage> 1.2.3-alpha.3 serait autorisée à correspondre à la version 1.2.3-alpha.7, mais elle ne serait pas satisfaite par 3.4.5-alpha.9, même si 3.4.5-alpha .9 est techniquement "supérieur à" 1.2.3-alpha.3 selon les règles de tri SemVer. La gamme de versions accepte uniquement les balises d'avant-version sur la version 1.2.3. La version 3.4.5 satisferait la plage, car elle n'a pas d'indicateur de pré-publication, et 3.4.5 est supérieur à 1.2.3-alpha.7.

Idée 2 Encore une fois, c'est un autre "hack". Si vous êtes prêt à perdre la partie patch de SemVer, vous pouvez publier vos versions en tant que

x.x.<unix Epoch ms>.

L'époque unix est en constante augmentation (au moins jusqu'en 2038 pour 32 bits) et chaque fois que vous publiez, vous publierez toujours une version plus grande.

25
dustin.schultz