Quelle est la différence entre npm-emballé.JSON et package-lock.json?
Avec la version de npm@5, Il va maintenant écrire un package-lock.json sauf si un npm-shrinkwrap.json existe déjà.
J'ai installé npm@5 globalement via:
npm install npm@5 -g
Et maintenant, si un npm-shrinkwrap.json est 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 emporter est que je devrais remplacer le shrinkwrap par le package-lock.json.
Pourtant, pourquoi y a-t-il un nouveau format pour cela? Que peut faire le package-lock.json que le npm-shrinkwrap.json ne peut pas faire?
3 réponses
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 gère, décrites sur le site docs et aussi dans un fichier docs dans le dépôt npm qui commence par aborder explicitement la différence entre ces deux fichiers :
-
package-lock.jsonn'est jamais publié de mnp, tandis quenpm-shrinkwrapest par défaut -
package-lock.jsonles fichiers qui ne sont pas dans le package de niveau supérieur sont ignorés, mais les fichiers shrinkwrap appartenant à des dépendances sont respecté -
{[3] } est rétrocompatible avec les versions 2, 3 et 4 de npm, alors que
package-lock.jsonn'est reconnu que par npm 5 +
, Vous pouvez convertir un package-lock.json pour un npm-shrinkwrap.json par l'exécution de npm shrinkwrap.
Ainsi:
- Si vous ne publiez pas votre paquet sur npm, le choix entre ces deux fichiers est peu important. Vous pouvez 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 utilisernpm-shrinkwrap.jsonpour rétrocompatibilité avec npm 2-4 s'il vous est difficile de vous assurer que tout le monde de votre équipe de développement est sur npm 5+. (Notez que npm 5 a été publié le 25th May 2017; la rétrocompatibilité deviendra de moins en moins importante à partir de cette date, car la plupart des gens finiront par mettre à niveau.) -
Si vouspubliez votre paquet sur npm, vous avez le choix entre:
- en utilisant un
package-lock.jsonpour enregistrer exactement quelles versions de dépendances vous installé, mais permettant aux personnes qui installent votre package d'utiliser n'importe quelle version des dépendances compatible avec les plages de versions dictées par votrepackage.jsonou - en utilisant un
npm-shrinkwrap.jsonpour garantir que tous ceux qui installent votre paquet obtiennent exactement la même version de toutes les dépendances
la vue officielle décrite (très laconiquement) dans les documents est que l'option 1 devrait être utilisée pour les bibliothèques (probablement afin de réduire la quantité de duplication de paquets causé quand beaucoup de dépendances d'un paquet 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. - en utilisant un
Explication du développeur NPM :
L'idée est définitivement pour package-lock.json pour être le dernier et Plus grand dans la technologie shrinkwrap, et npm-shrinkwrap.json pour être réservé à ces quelques personnes précieuses là bas qui se soucient beaucoup A propos de leurs bibliothèques ayant un node_modules exact - et pour les personnes qui veulent CI en utilisant npm@> = 2 pour installer un arbre particulier sans avoir pour cogner sa version npm.
Le nouveau fichier de verrouillage ("package-lock.json") actions essentiellement tous les même code, exactement le même format que npm-emballé (vous pouvez renommer entre l'un de l'autre!). C'est aussi quelque chose que la communauté semble comprendre: "il a un fichier de verrouillage" semble cliquer beaucoup plus rapidement avec gens. Enfin, avoir un nouveau fichier signifiait que nous pourrions avoir relativement faible risque vers l'arrière-compat avec shrinkwrap sans avoir à faire bizarre des choses comme allow-publication mentionné dans le message parent.
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 qui se passe 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:
La citation pertinente:
Npm publie la plupart des fichiers dans votre source répertoire par défaut, et les gens publient des shrinkwraps depuis des années. Nous ne voulions pas compatibilité de rupture. Avec --save et shrinkwrap par défaut, il y avait un grand risque de le faire accidentellement et de se propager à travers le registre, et essentiellement rendre notre capacité à mettre à jour deps et la déduplication... NULL.
Nous avons Donc choisi un nouveau nom. Et nous avons choisi un nouveau nom soudain. Le nouveau lockfile partage essentiellement tout le même code, le exactement la même format