npm @ 5 a été publié, il a un nouveau fichier package-lock.json (après npm install
) qui me déroute. Je veux savoir, quel est l'effet de ce fichier?
npm @ 5 a été publié, il a un nouveau fichier package-lock.json (après npm install
) qui me déroute. Je veux savoir, quel est l'effet de ce fichier?
Réponses:
Il stocke un arbre de dépendance versionné exact plutôt que d'utiliser un versionnement étoilé comme package.json lui-même (par exemple 1.0. *). Cela signifie que vous pouvez garantir les dépendances pour d'autres développeurs ou versions de prod, etc. Il dispose également d'un mécanisme pour verrouiller l'arborescence mais se régénérera généralement si package.json change.
À partir des documents npm :
package-lock.json est généré automatiquement pour toutes les opérations où npm modifie l'arborescence node_modules ou package.json. Il décrit l'arborescence exacte qui a été générée, de sorte que les installations suivantes peuvent générer des arborescences identiques, quelles que soient les mises à jour des dépendances intermédiaires.
Ce fichier est destiné à être validé dans les référentiels sources et sert à diverses fins:
Décrivez une représentation unique d'une arborescence de dépendances telle que les coéquipiers, les déploiements et l'intégration continue sont garantis pour installer exactement les mêmes dépendances.
Fournir aux utilisateurs la possibilité de "voyager dans le temps" vers les états précédents de node_modules sans avoir à valider le répertoire lui-même.
Pour faciliter une plus grande visibilité des changements d'arbre grâce à des différences de contrôle de source lisibles.
Et optimisez le processus d'installation en permettant à npm d'ignorer les résolutions de métadonnées répétées pour les packages déjà installés. "
Pour répondre à la question de jrahhali ci-dessous sur l'utilisation du package.json avec les numéros de version exacts. Gardez à l'esprit que votre package.json contient uniquement vos dépendances directes, pas les dépendances de vos dépendances (parfois appelées dépendances imbriquées). Cela signifie qu'avec le package.json standard, 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 entre pairs n'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 arborescence de dépendances complète sera identique à chaque fois. Deuxièmement, vous voudrez peut-être autoriser des modifications incessantes (basées 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 plus garantir que vos dépendances directes ne briseront à aucun moment les règles de versioning sémantique se.
La solution à tout cela est le fichier de verrouillage qui, comme décrit ci-dessus, verrouille les versions de l'arborescence de dépendance complète. Cela vous permet de garantir votre arbre de dépendances pour d'autres développeurs ou pour des versions tout en permettant de tester de nouvelles versions de dépendances (directes ou indirectes) à l'aide de votre package.json standard.
NB. Le précédent emballage rétractable json a 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'habillage rétractable dans le projet, il sera utilisé à la place de tout fichier de verrouillage.
package-lock.json
fichier est mis à jour à chaque fois que vous appelez npm install depuis NPM 5.1. (modification dans github.com/npm/npm/issues/16866 , exemple dans github.com/npm/npm/issues/17979 ) Il ne peut donc plus être utilisé pour définir les mêmes versions pour tous les développeurs , sauf si vous spécifiez des versions exactes comme 1.2.3
au lieu de 1.2.*
dans votre package.json
fichier.
npm ci
as npm install
mettra à jour le package-lock.json tandis que ci utilise son contenu. Ce n'est qu'avec npm ci
que vous obtiendrez des versions robustes reproductibles.
C'est une amélioration très importante pour npm: garantir exactement la même version de chaque paquet .
Comment vous assurer que votre projet est construit avec les mêmes packages dans des environnements différents à un moment différent? Disons que vous pouvez utiliser ^1.2.3
dans votre package.json
, ou certaines de vos dépendances utilisent de cette façon, mais comment pouvez-vous vous assurer que chaque fois npm install
récupérera la même version dans votre machine de développement et dans le serveur de build? package-lock.json veillera à ce que.
npm install
va recréer le fichier de verrouillage, lorsque 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 package)
package-lock.json
fichier. Il s'installe simplement package.json
comme auparavant. Pour utiliser le package-lock.json
fichier, vous devez utiliser la nouvelle commande "npm ci", qui installera les versions exactes répertoriées dans package-lock.json
au lieu des plages de versions indiquées dans package.json
.
npm install
ne lit de package-lock.json
. Pour reproduire, procédez comme suit. en utilisant ce package.json, exécutez npm install
{... "devDependencies": {"sinon": "7.2.2"}} Maintenant, copiez / collez package.json
et package-lock.json
dans un nouveau répertoire. Changez package.json
pour: "sinon": "^ 7.2.2" exécutez npm install
. npm lit à partir de package-lock.json et installe 7.2.2 au lieu de 7.3.0. Sans package-lock.json, 7.3.0 serait installé.
package-lock.json
, la seule façon raisonnable de le faire est de le supprimer package-lock.json
et de le régénérer en utilisant npm install
. (Vous ne souhaitez pas modifier manuellement package-lock.json
). Changer la valeur de la propriété "version" (près du haut) de package.json
changera la même chose dans package-lock.json
on npm install
, mais ajouter un caret à une dépendance ne fera pas de même package-lock.json
.
package.json
comme quelque chose que vous pouvez modifier manuellement et package-lock.json
comme quelque chose que vous ne touchez jamais manuellement. Vous contrôlez toujours la version des DEUX fichiers - en particulier package-lock.json
. Ouvrez les deux fichiers, modifiez manuellement le nom du projet package.json
, exécutez npm install
et observez comment le nom du projet change package-lock.json
. license
ne semble pas être enregistré en package-lock.json
.
npm ci
, npm install
n'utilisera que package.json, même si le fichier de verrouillage est fourni
package-lock.json
est écrit 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 package.json
.
Si ces valeurs numériques dans package.json
et package-lock.json
correspondent, package-lock.json
est lue à partir de.
Si ces valeurs numériques dans package.json
et package-lock.json
ne correspondent pas, package-lock.json
est écrit avec ces nouvelles valeurs, et de nouveaux modificateurs tels que le curseur et le tilde s'ils sont présents. Mais c'est le chiffre qui déclenche le changement vers package-lock.json
.
Pour voir ce que je veux dire, procédez comme suit. En utilisant package.json
sans package-lock.json
, exécutez npm install
avec:
{
"name": "test",
"version": "1.0.0",
...
"devDependencies": {
"sinon": "7.2.2"
}
}
package-lock.json
aura désormais:
"sinon": {
"version": "7.2.2",
Copiez / collez maintenant les deux fichiers dans un nouveau répertoire. Remplacer package.json
par (ajouter uniquement le signe insertion):
{
"name": "test",
"version": "1.0.0",
...
"devDependencies": {
"sinon": "^7.2.2"
}
}
courir npm install
. S'il n'y avait pas de package-lock.json
fichier, sinon@7.3.0 serait installé. npm install
est la lecture à partir package-lock.json
et l' installation 7.2.2.
Maintenant, changez package.json
pour:
{
"name": "test",
"version": "1.0.0",
...
"devDependencies": {
"sinon": "^7.3.0"
}
}
courir npm install
. package-lock.json
a été écrit et affichera désormais:
"sinon": {
"version": "^7.3.0",
Une chose importante à mentionner également est l'amélioration de la sécurité fournie avec le fichier package-lock. Comme il conserve tous les hachages des packages si quelqu'un altère le registre public npm et modifie le code source d'un package sans même changer la version du package lui-même, il sera détecté par le fichier de verrouillage de package.
package-lock.json est généré automatiquement pour toutes les opérations où npm modifie l'arborescence node_modules ou package.json. Il décrit l'arborescence exacte qui a été générée, de sorte que les installations suivantes peuvent générer des arborescences identiques, quelles que soient les mises à jour des dépendances intermédiaires.
Il décrit une représentation unique d'une arborescence de dépendances telle que coéquipiers, déploiements et intégration continue sont garantis pour 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"
}
},
}
Ce fichier est automatiquement créé et utilisé par npm pour garder une trace des installations de vos packages et pour mieux gérer l'état et l'historique des dépendances de votre projet. Vous ne devez pas modifier le contenu de ce fichier.
package-lock.json: il contient les détails exacts de la version actuellement installée pour votre application.