web-dev-qa-db-fra.com

Quel est le rôle du package-lock.json?

npm @ 5 a été publié, il a une nouvelle fonctionnalité package-lock.json fichier (après npm install) qui me déroute. Je veux savoir, quel est l'effet de ce fichier?

npm
177
SecretCastle

Il stocke une arborescence de dépendances versée exacte plutôt que d'utiliser un versioning étoilé comme package.json lui-même (par exemple 1.0. *). Cela signifie que vous pouvez garantir les dépendances des autres développeurs ou des versions de prod, etc. Il dispose également d'un mécanisme pour verrouiller l'arborescence mais se régénère généralement si package.json est modifié.

De les documents npm :

package-lock.json est automatiquement généré pour toutes les opérations où npm modifie l'arborescence node_modules ou package.json. Il décrit l'arborescence exacte générée, de sorte que les installations ultérieures puissent générer des arborescences identiques, quelles que soient les mises à jour de dépendance intermédiaires.

Ce fichier est destiné à être validé dans les référentiels sources et sert à plusieurs fins:

Décrivez une représentation unique d'un arbre de dépendance de sorte que les coéquipiers, les déploiements et l'intégration continue soient garantis pour installer exactement les mêmes dépendances.

Fournissez aux utilisateurs une 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 modifications d'arborescence via des diffs 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 précédemment installés. "

Modifier

Pour répondre à la question ci-dessous de Jrahhali sur l'utilisation du package.json avec les numéros de version exacts. N'oubliez pas 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 fichier standard package.json, vous ne pouvez pas contrôler les versions de ces dépendances imbriquées. Les référencer directement ou comme dépendances entre homologues ne vous aidera pas, car vous ne contrôlerez pas non plus la tolérance de version définie par vos dépendances directes 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 pouvez autoriser des modifications ininterrompues (basées sur le versioning sémantique) de vos dépendances directes, ce qui vous donne encore moins de contrôle sur les dépendances imbriquées. De plus, vous ne pouvez plus garantir que vos dépendances directes ne vont pas, à un moment donné, briser les règles de versioning sémantiques se.

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épendance à d'autres développeurs ou à des versions tout en permettant de tester de nouvelles versions de dépendance (directes ou indirectes) à l'aide de votre package standard.json.

NB Le précédent film rétractable json faisait à peu près la même chose, mais le fichier de verrouillage le renomme afin que sa fonction soit plus claire. S'il y a déjà un fichier d'emballage sous film dans le projet, il sera utilisé à la place de tout fichier verrou.

169
Matt

C'est une amélioration très importante pour npm: garantit exactement la même version de chaque paquet.

Comment vous assurer que votre projet est construit avec les mêmes packages dans différents environnements et à différentes époques? Supposons que vous puissiez utiliser _^1.2.3_ dans votre _package.json_, ou que certaines de vos dépendances l'utilisent de cette manière, mais comment vous assurer que chaque fois que _npm install_ récupèrera la même version sur votre machine et dans le serveur de construction? package-lock.json assurera cela.

_npm install_ générera le fichier de verrouillage lorsque vous utiliserez un serveur de génération ou un serveur de déploiement, _npm ci_ (qui lira le fichier de verrouillage et installera l’ensemble de l’arborescence du package).

9
Xin

package-lock.json est écrit dans 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, il en résulte la lecture de package-lock.json.

Si ces valeurs numériques dans package.json et package-lock.json ne correspondent pas, il est écrit package-lock.json avec ces nouvelles valeurs, ainsi que de nouveaux modificateurs tels que le caret et le tilde s'ils sont présents. Mais c'est le chiffre qui déclenche le changement de 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 maintenant:

"sinon": {
  "version": "7.2.2",

Maintenant, copiez/collez les deux fichiers dans un nouveau répertoire. Remplacez package.json par (en ajoutant seulement le curseur):

{
  "name": "test",
  "version": "1.0.0",
  ...
  "devDependencies": {
    "sinon": "^7.2.2"
  }
}

lancez npm install. S'il n'y avait pas de fichier package-lock.json, [email protected] serait installé. npm install est lecture depackage-lock.json et installation de 7.2.2.

Maintenant changez package.json en:

{
  "name": "test",
  "version": "1.0.0",
  ...
  "devDependencies": {
    "sinon": "^7.3.0"
  }
}

lancez npm install. package-lock.json a été écrit sur, et montrera maintenant:

"sinon": {
  "version": "^7.3.0",
5
zumafra

package-lock.json est automatiquement généré pour toutes les opérations où npm modifie l'arborescence node_modules ou package.json. Il décrit l'arborescence exacte générée, de sorte que les installations ultérieures puissent générer des arborescences identiques, quelles que soient les mises à jour de dépendance intermédiaires.

Il décrit une représentation unique d'un arbre de dépendance, de sorte que les coéquipiers, les déploiements et l'intégration continue ont la garantie 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"
  }
},

}

1
DIBYA RANJAN TRIPATHY

Une autre chose importante à mentionner est l'amélioration de la sécurité fournie avec le fichier de verrouillage de paquet. Puisqu'il conserve tous les hachages des paquets, si quelqu'un altère le registre public npm et modifie le code source d'un paquet sans même changer la version du paquet lui-même, il sera détecté par le fichier package-lock.

1
nflaig