Quelle est la différence entre npm-shrinkwrap.json et package-lock.json ?

Question

Avec le version de npm@5 il va maintenant écrire un package-lock.json à moins qu'un npm-shrinkwrap.json existe déjà.

J'ai installé npm@5 de manière globale via :

npm install npm@5 -g

Et maintenant, si un npm-shrinkwrap.json se trouve pendant :

npm install

un avertissement sera imprimé :

npm WARN read-shrinkwrap This version of npm
is compatible with lockfileVersion@1,
but npm-shrinkwrap.json was generated for lockfileVersion@0.
I'll try to do my best with it!

J'en déduis donc que je devrais remplacer le shrinkwrap par le package-lock.json .

Mais pourquoi un nouveau format ? Que peut faire le package-lock.json faire que le npm-shrinkwrap.json ne peut pas ?

Answer 1

Les fichiers ont exactement le même contenu, mais il y a une poignée de différences dans la façon dont npm les traite, la plupart d'entre elles étant notées dans les pages de la docs de paquet-lock.json y npm-shrinkwrap.json :

• package-lock.json n'est jamais publié sur npm, alors que npm-shrinkwrap est par défaut
• package-lock.json les fichiers qui ne sont pas dans le paquet de premier niveau sont ignorés, mais les fichiers shrinkwrap appartenant aux dépendances sont respectés
• npm-shrinkwrap.json est rétrocompatible avec les versions 2, 3 et 4 de npm, alors que package-lock.json n'est reconnu que par npm 5+

Vous pouvez convertir une package-lock.json à un npm-shrinkwrap.json en courant npm shrinkwrap .

Ainsi :

• Si vous ne publiez pas votre paquet sur npm, le choix entre ces deux fichiers n'a que peu d'importance. Vous pouvez souhaiter utiliser package-lock.json parce que c'est la valeur par défaut et que son nom est plus clair pour les débutants de npm ; alternativement, vous pouvez utiliser npm-shrinkwrap.json pour la rétrocompatibilité avec npm 2-4 s'il vous est difficile de vous assurer que tous les membres de votre équipe de développement sont sur npm 5+. (Notez que npm 5 a été publié le 25 mai 2017 ; la rétrocompatibilité deviendra de moins en moins importante à mesure que nous nous éloignerons de cette date, car la plupart des gens finiront par effectuer une mise à niveau).

• Si vous sont en publiant votre paquet à npm, vous avez le choix entre deux possibilités :

  1. en utilisant un package-lock.json pour enregistrer exactement les versions des dépendances que vous avez installées, mais en permettant aux personnes qui installent votre paquet d'utiliser n'importe quelle version des dépendances qui est compatible avec les plages de version dictées par vos package.json ou
  2. en utilisant un npm-shrinkwrap.json pour garantir que tous ceux qui installent votre paquet obtiennent exactement la même version de toutes les dépendances

  Le point de vue officiel décrit dans la documentation est que l'option 1 doit être utilisée pour les bibliothèques (vraisemblablement afin de réduire la quantité de paquets dupliqués lorsque de nombreuses dépendances d'un paquet dépendent toutes de versions légèrement différentes de la même dépendance secondaire), mais que l'option 2 peut être raisonnable pour les exécutables qui vont être installés globalement.

Answer 2

Explication du développeur NPM :

L'idée est définitivement que package-lock.json soit le dernier et le plus grand technologie shrinkwrap, et que npm-shrinkwrap.json soit réservé aux quelques réservé aux quelques rares personnes qui se soucient beaucoup à ce que leurs bibliothèques aient un node_modules exact -- et pour les personnes qui veulent que CI utilise npm@>=2 pour installer une arborescence particulière sans avoir à sans avoir à modifier sa version npm.

Le nouveau fichier de verrouillage ("package-lock.json") partage essentiellement le même même code, le même format que npm-shrinkwrap (vous pouvez les renommer entre eux !). C'est aussi quelque chose que la communauté semble comprendre : "il a un fichier de verrouillage" semble faire tilt bien plus vite auprès des gens. les gens. Enfin, avoir un nouveau fichier signifiait que nous pouvions avoir un risque relativement faible. relativement peu risqué de rétrocompatibilité avec shrinkwrap sans avoir à faire des choses comme allow-publication mentionné dans le post parent.

Answer 3

Je pense que l'idée était d'avoir --save et shrinkwrap par défaut, mais d'éviter tout problème potentiel avec un shrinkwrap se produisant là où il n'était pas souhaité. Donc, ils lui ont simplement donné un nouveau nom de fichier pour éviter tout conflit. Quelqu'un de npm l'a expliqué plus en détail ici :

https://www.reddit.com/r/javascript/comments/6dgnnq/npm_v500_released_save_by_default_lockfile_better/di3mjuk/

La citation pertinente :

npm publie la plupart des fichiers dans votre répertoire source par défaut, et les gens publient des shrinkwraps depuis des années. Nous ne voulions pas rompre la compatibilité. Avec le --save et le shrinkwrap par défaut, il y avait un grand risque de le faire accidentellement et de le propager à travers le registre, et fondamentalement rendre notre capacité à mettre à jour les deps et déduplication... nulle.

Nous avons donc choisi un nouveau nom. Et nous avons choisi un nouveau nom tout d'un coup. soudain. Le nouveau fichier lockfile partage en gros le même code. exactement le même format

Answer 4

package-lock.json sont garanties avec seulement npm ci ( depuis npm install écrase package-lock.json s'il y a un conflit avec package.json ).

npm-shrinkwrap.json sont garanties à la fois avec npm ci y npm install .