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

158

Avec la sortie de npm @ 5 , il écrira désormais a package-lock.jsonsauf si un npm-shrinkwrap.jsonexiste déjà.

J'ai installé npm @ 5 dans le monde via:

npm install npm@5 -g

Et maintenant, si un npm-shrinkwrap.jsonest trouvé 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!

Donc, mon point à retenir est que je devrais remplacer l'emballage rétractable par le package-lock.json.

Pourtant, pourquoi y a-t-il un nouveau format pour cela? Que peuvent package-lock.jsonfaire les npm-shrinkwrap.jsonnon?

npm npm-shrinkwrap package-lock.json

— k0pernikus
source

Réponses:

176

Les fichiers ont exactement le même contenu, mais il existe une poignée de différences dans la façon dont npm les gère, décrites sur le site de documentation et également dans un fichier de documentation dans le dépôt npm qui commence par traiter explicitement la différence entre ces deux fichiers :

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

Vous pouvez convertir un existant package-lock.jsonen un npm-shrinkwrap.jsonen exécutant npm shrinkwrap.

Donc:

Si vous ne publiez pas votre package sur npm, le choix entre ces deux fichiers est sans conséquence. Vous souhaiterez peut-être l'utiliser package-lock.jsoncar c'est la valeur par défaut et son nom est plus clair pour les débutants npm; Vous pouvez également utiliser npm-shrinkwrap.jsonpour la compatibilité descendante 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 est sorti 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 mettre à niveau.)
Si vous êtes publiez votre colis à NPM, vous avez le choix entre:
1. en utilisant a package-lock.jsonpour enregistrer exactement les versions des dépendances que vous avez installées, mais en permettant aux personnes installant votre package d'utiliser n'importe quelle version des dépendances compatible avec les plages de versions dictées par votre package.json, ou
2. en utilisant un npm-shrinkwrap.jsonpour garantir que tous ceux qui installent votre package obtiennent exactement la même version de toutes les dépendances
Le point de vue officiel décrit (très brièvement) dans la documentation est que l'option 1 doit être utilisée pour les bibliothèques (probablement afin de réduire la quantité de duplication de package causée lorsque de nombreuses dépendances d'un package dépendent toutes de versions légèrement différentes de la même dépendance secondaire) , mais cette option 2 peut être raisonnable pour les exécutables qui vont être installés globalement.

— Mark Amery
source

+1 - Pouvez-vous clarifier votre deuxième point? Quelle est la différence entre ce comportement et le fait d'avoir un npm-shrinkwrap?

— Rhys

@Rhys la deuxième puce n'aura pas d'importance dans la pratique à moins que vous ne fassiez quelque chose de bizarre. En gros, il dit simplement que si une bibliothèque en quelque sorte fait publier un package-lock.json( ce qui est impossible), alors si vous deviez installer cette bibliothèque comme une dépendance d'un autre paquet, la bibliothèque de package-lock.jsonseraient ignorés par NPM. Cependant, si une bibliothèque publie un npm-shrinkwrap.jsonfichier et que vous installez la bibliothèque en tant que dépendance, vous installerez également en tant que dépendances secondaires les versions exactes de toutes les dépendances spécifiées dans la bibliothèque npm-shrinkwrap.json.

— Mark Amery du

Pouvez-vous s'il vous plaît ajouter qui npm ciexiste pour assurer l'installation du package-lock.jsonen lecture seule. ( npm installmute la package-lock.jsonconfusion qui cause et les bogues potentiels et ne profite pas du package-lock.jsonper se.)

— k0pernikus

@ k0pernikus Je ne pense pas qu'il y ait de différence entre comment npm cigère npm-shrinkwrap.jsonet package-lock.json- quelle est sa pertinence par rapport à cette question sur la différence entre les deux fichiers? Aussi, après avoir lu: je pense que " npm install... ne profite pas du package-lock.json" a été faux depuis npm 5.4 - je crois npm installmaintenant respecte votre package-lock sauf si c'est carrément incompatible avec le vôtre package.json, auquel cas ce dernier prévaudra. (Mais je suis un peu hors du monde JavaScript - est-ce que je manque quelque chose?)

— Mark Amery

Explication du développeur NPM :

L'idée est définitivement que package-lock.json soit le dernier et le plus grand de la technologie shrinkwrap, et que npm-shrinkwrap.json soit réservé à ces quelques précieuses personnes qui se soucient beaucoup de leurs bibliothèques ayant un node_modules exact - et pour les personnes qui veulent que CI utilisant npm @> = 2 pour installer un arbre particulier sans avoir à modifier sa version npm.

Le nouveau fichier de verrouillage ("package-lock.json") partage essentiellement le même code, exactement 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 cliquer beaucoup plus vite avec les gens. Enfin, avoir un nouveau fichier signifiait que nous pouvions avoir une compatibilité descendante relativement faible avec le film rétractable sans avoir à faire des choses étranges comme autoriser la publication mentionnée dans le message parent.

— SeriousM
source

Je ne suis toujours pas clair sur la différence. Si npm-shrinkwrapc'est pour node_modules exact .... Je suppose que le package-lock.jsonverrouillage est moins qu'exact ? Et si tel est le cas, qu'est-ce que le verrouillage n'est pas le npm-shrinkwrapverrouillage?

— dman le

vous vous êtes trompé @dman. package-lock est la nouvelle version de npm-shrinkwrap. package-lock est opt-out (vous devez donc supprimer la fonctionnalité car elle est activée par défaut), npm-shrinkwrap est opt-in (vous devez donc l'activer car elle n'est pas incluse par défaut). la raison pour laquelle ils ont introduit package-lock est que 1. l'utilisateur dispose désormais d'un moyen économiseur de gérer les dépendances car il est activé par défaut et 2. le nom implique ce qu'il est à l'opposé de "shrinkwrap". npm-shrinkwrap avait des paramètres de comportement de dépendance spéciaux que package-lock n'a pas maintenant. npm-shrinkwrap est maintenant obsolète.

— SeriousM

Ceci est une erreur. En disant que package-lock est la nouvelle version de npm-shrinkwrap, vous dites que c'est un remplacement. npm-shrinkwrap n'est pas obsolète et présente des différences avec package-lock.json. De plus, package-lock.json a un bogue alors que npm-shrinkwrap ne le fait pas ... accentuant ainsi davantage qu'ils ne sont pas le même code.

— dman

Package-lock.json est également intrusif. Cela peut donc facilement provoquer des conflits scm si vous appelez "npm i" alors que le shrinkwrap doit être généré explicitement et ne provoquera pas de conflits sur les serveurs ci. Oui, je peux me tromper ici.

— norekhov

@dman "package-lock.json a un bogue alors que npm-shrinkwrap n'en a pas" - non, ce n'est pas le cas. Il n'y a aucune indication de cela dans le problème auquel vous êtes lié; il ne mentionne même pas npm-shrinkwrap. Comme je le note dans ma réponse, la conversion de a package-lock.jsonen an se npm-shrinkwrap.jsonfait littéralement en renommant le fichier; ce sont "le même code".

— Mark Amery

Je pense que l'idée était que --save et shrinkwrap se produisent par défaut, mais évitez tout problème potentiel avec un film rétractable là où il n'était pas voulu. Donc, ils lui ont juste 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 films rétractables depuis des années. Nous ne voulions pas rompre la compatibilité. Avec --save et shrinkwrap par défaut, il y avait un grand risque qu'il entre accidentellement et se propage dans le registre, et rende fondamentalement notre capacité à mettre à jour deps et à dédupliquer ... null.

Nous avons donc choisi un nouveau nom. Et nous avons tout d'un coup choisi un nouveau nom. Le nouveau fichier de verrouillage partage essentiellement le même code, exactement le même format

— Cody Brumfield
source