Npm@5 a été publié, il comporte une nouvelle fonctionnalité package-lock.json (après npm install ), ce qui me perturbe. Je veux savoir quel est l'effet de ce fichier ?
Il stocke un arbre de dépendances exact et versionné plutôt que d'utiliser un versionnage en étoile comme package.json lui-même (par exemple, 1.0.*). Cela signifie que vous pouvez garantir les dépendances pour les autres développeurs ou les versions de production, etc. Il dispose également d'un mécanisme pour verrouiller l'arbre, mais en général, il se régénère si package.json changements.
package-lock.json est automatiquement généré pour toute opération où npm modifie soit l'arbre node_modules, soit package.json. Il décrit l'arbre exact qui a été généré, de sorte que les installations ultérieures puissent générer des arbres identiques, indépendamment des mises à jour intermédiaires des dépendances.
Ce fichier est destiné à être livré dans les dépôts de sources, et sert à plusieurs fins :
Décrire une représentation unique d'un arbre de dépendances de telle sorte que les coéquipiers, les déploiements et l'intégration continue soient garantis d'installer exactement les mêmes dépendances.
Fournir une facilité pour les utilisateurs de "voyager dans le temps" à des états précédents de node_modules sans avoir à commettre le répertoire lui-même.
Pour faciliter une plus grande visibilité des modifications de l'arbre grâce à des diffs de contrôle de source lisibles.
Et optimiser le processus d'installation en permettant à npm de sauter les résolutions de métadonnées répétées pour les paquets précédemment installés."
Pour répondre à la question de jrahhali, ci-dessous, concernant l'utilisation de l'outil de gestion de l'information. package.json avec les numéros de version exacts. Gardez à l'esprit que votre package.json contient uniquement vos dépendances directes, et non les dépendances de vos dépendances (parfois appelées dépendances imbriquées). Cela signifie qu'avec la méthode standard package.json vous ne pouvez pas contrôler les versions de ces dépendances imbriquées, les référencer directement ou en tant que dépendances homologues ne vous aidera pas car vous ne contrôlez pas non plus la tolérance de version que vos dépendances directes définissent pour ces dépendances imbriquées.
Même si vous verrouillez les versions de vos dépendances directes, vous ne pouvez pas garantir à 100% que votre arbre de dépendances complet sera identique à chaque fois. Deuxièmement, vous pourriez vouloir autoriser des changements non cassants (basés sur le versionnage sémantique) de vos dépendances directes, ce qui vous donne encore moins de contrôle sur les dépendances imbriquées, et vous ne pouvez pas garantir que vos dépendances directes n'enfreindront pas à un moment donné les règles de versionnage sémantique elles-mêmes.
La solution à tout cela est le fichier de verrouillage qui, comme décrit ci-dessus, verrouille les versions de l'arbre de dépendance complet. Cela vous permet de garantir votre arbre de dépendances pour d'autres développeurs ou pour des versions tout en permettant de tester les nouvelles versions de dépendances (directes ou indirectes) en utilisant votre fichier de verrouillage standard. package.json .
NB. Le précédent npm-shrinkwrap.json fait à peu près la même chose mais le fichier de verrouillage le renomme pour que sa fonction soit plus claire. S'il y a déjà un fichier d'emballage rétractable dans le projet, il sera utilisé à la place du fichier de verrouillage.
Si le fait d'avoir une version exacte des dépendances est si recherché, pourquoi ne pas imposer la spécification de la version exacte dans package.json et renoncer à un fichier package-lock.json ?
Comment cet arbre de dépendance de pacakge.json.lock est-il appliqué pour les autres développeurs ? Automatiquement ?
C'est une amélioration très importante pour npm : garantir exactement la même version de chaque paquet .
Comment s'assurer que votre projet est construit avec les mêmes paquets dans des environnements différents et à des moments différents ? Disons que vous pouvez utiliser ^1.2.3 dans votre package.json ou certaines de vos dépendances l'utilisent de cette façon, mais comment pouvez-vous vous assurer que chaque fois que npm install va récupérer la même version dans votre machine de développement et dans le serveur de construction ? paquet-lock.json permettra de s'en assurer.
npm install va re-générer le fichier de verrouillage.
Lorsque vous êtes sur le serveur de construction ou le serveur de déploiement, faites npm ci
(qui lira le fichier de verrouillage et installera l'arborescence complète du paquet)
Notez qu'elle est un peu dépassée maintenant. À partir de la version 5.1.0, "npm install" ne lit pas les données de la base de données de l'application package-lock.json du tout. Il s'installe simplement à partir de package.json comme avant. Pour utiliser le package-lock.json vous devez utiliser la nouvelle commande "npm ci", qui installera les versions exactes listées dans le fichier package-lock.json au lieu des gammes de versions indiquées dans package.json .
Je crains que Venryx n'ait tort. npm install fait lire à partir de package-lock.json . Pour reproduire, faites ce qui suit. En utilisant ce package.json, exécutez npm install { ... "devDependencies" : { "sinon" : "7.2.2" } } Maintenant, copier/coller package.json y package-lock.json dans un nouveau répertoire. Changez package.json à : "sinon" : "^7.2.2" run npm install . npm lit dans package-lock.json et installe 7.2.2 au lieu de 7.3.0. Sans package-lock.json, la version 7.3.0 serait installée.
Et pas seulement cela, mais si vous voulez faire quelque chose comme ajouter le signe d'insertion ^ à package-lock.json la seule façon raisonnable de faire cela est de supprimer package-lock.json et le régénérer en utilisant npm install . (Vous ne voulez pas modifier manuellement package-lock.json ). En changeant la valeur de la propriété "version" (vers le haut) de l'application package.json changera de la même manière dans package-lock.json sur npm install mais l'ajout d'un signe d'insertion à une dépendance n'aura pas le même effet sur l'utilisateur. package-lock.json .
package-lock.json est écrite lorsqu'une valeur numérique dans une propriété telle que la propriété "version", ou une propriété de dépendance est modifiée dans le fichier package.json .
Si ces valeurs numériques dans package.json y package-lock.json match, package-lock.json est lu.
Si ces valeurs numériques dans package.json y package-lock.json ne correspondent pas, package-lock.json est écrit avec ces nouvelles valeurs, et les nouveaux modificateurs tels que l'insigne et le tilde s'ils sont présents. Mais c'est le numéral qui déclenche le changement en package-lock.json .
Pour voir ce que je veux dire, faites ce qui suit. En utilisant package.json sans package-lock.json , courir npm install avec :
{
"name": "test",
"version": "1.0.0",
...
"devDependencies": {
"sinon": "7.2.2"
}
}package-lock.json auront désormais :
"sinon": {
"version": "7.2.2",Maintenant, copiez/collez les deux fichiers dans un nouveau répertoire. Changez package.json à (en ajoutant seulement le signe d'insertion) :
{
"name": "test",
"version": "1.0.0",
...
"devDependencies": {
"sinon": "^7.2.2"
}
}exécuter npm install . S'il n'y avait pas package-lock.json sinon@7.3.0 sera installé. npm install es la lecture de package-lock.json et en installant 7.2.2.
Maintenant, changez package.json à :
{
"name": "test",
"version": "1.0.0",
...
"devDependencies": {
"sinon": "^7.3.0"
}
}exécuter npm install . package-lock.json a été écrit à et s'affiche maintenant :
"sinon": {
"version": "^7.3.0",
Il convient également de mentionner l'amélioration de la sécurité apportée par le fichier package-lock. Comme il conserve tous les hashs des paquets, si quelqu'un manipulait le registre public npm et modifiait le code source d'un paquet sans même changer la version du paquet lui-même, il serait détecté par le fichier de verrouillage des paquets.
Package-lock.json est automatiquement généré pour toute opération où npm modifie soit l'arbre node_modules, soit package.json. Il décrit l'arbre exact qui a été généré, de sorte que les installations ultérieures puissent générer des arbres identiques, indépendamment des mises à jour intermédiaires des dépendances.
Il décrit une représentation unique d'un arbre de dépendances telle que les coéquipiers, les déploiements et l'intégration continue sont garantis d'installer exactement les mêmes dépendances.Il contient les propriétés suivantes.
{
"name": "mobileapp",
"version": "1.0.0",
"lockfileVersion": 1,
"requires": true,
"dependencies": {
"@angular-devkit/architect": {
"version": "0.11.4",
"resolved": "https://registry.npmjs.org/@angular- devkit/architect/-/architect-0.11.4.tgz",
"integrity": "sha512-2zi6S9tPlk52vyqNFg==",
"dev": true,
"requires": {
"@angular-devkit/core": "7.1.4",
"rxjs": "6.3.3"
}
},
} Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
Package-lock. json pour garder la trace des arbres de dépendances exacts à un moment donné. Cela garantira que tous les clients qui téléchargent votre projet et tentent d'installer des dépendances obtiendront exactement le même arbre de dépendances.