web-dev-qa-db-fra.com

Le fichier package-lock.json doit-il être ajouté à .gitignore?

Pour verrouiller les versions de dépendances installées sur un projet, utilisez la commande npm install crée un fichier nommé package-lock.json. Cela a été fait depuis Node.js v8.0. et npm v5.0. , comme plusieurs d'entre vous le savent peut-être.

En dépit de Node.js et npm recommandations concernant la validation de ce fichier, il est également possible de s'inquiéter du moment où vous devriez éviter de le faire. En règle générale, nous nous engageons dans nos projets. Néanmoins, il s’agit d’une question particulière.

Alors que nous devrions commettre le package-lock.json fichier par défaut, nous avons un cas spécifique que nous ne devrions pas. Par exemple, si nous souhaitons tester la dernière version de nos dépendances de projets, l’ajout de package-lock.json en .gitignore.

Donc, les questions sont les suivantes:

  1. Le package-lock.json le fichier soit ajouté à .gitignore?
  2. Existe-t-il une situation particulière dans laquelle nous [~ # ~] devons [~ # ~] ou NE DOIT PAS le faire?
javascriptnode.jsgitnpmgitignore
22
Francisco Maria Calisto

Non, le package-lock.json NE DEVRAIT PAS être ajouté à .gitignore. Au lieu de cela, je conseille fortement:

  1. Ajoutez le package-lock.json vous dans votre référentiel de contrôle de version
  2. Utilisez npm ci au lieu de npm install lors de la création de votre application à la fois localement et dans votre pipeline de déploiement.
    (La commande ci est disponible depuis [email protected], en cas de doute, mettez à niveau votre npm via:
    npm install -g npm.)

L’un des inconvénients majeurs de la commande npm install est son comportement inattendu, qui peut modifier le package-lock.json, alors que npm ci n’utilise que la version du fichier lock et génère un erreur si package-lock.json et package.json ne sont pas synchronisés.

En outre, npm ci nécessite l'existence d'un package-lock.json et afficherait une erreur s'il n'y en avait pas. Il existe de nombreux cas d'utilisation permettant de croire que les dépendances du projet sont résolues de manière répétée de manière fiable sur différentes machines.

En outre, npm ci numérise l'intégralité du dossier node_modules avant d'ajouter les dépendances en veillant à ce que vous travailliez avec vos dépendances réelles au lieu de modifications locales, tout en restant plus rapide qu'un npm install normal. .

D'un package-lock.json vous obtenez exactement cela: un état connu pour fonctionner.

Auparavant, j’avais des projets sans package-lock.json/npm-shrinkwrap.json/yarn.lock fichiers dont la construction échouerait un jour car une dépendance aléatoire avait été mise à jour. (Bien que beaucoup de bibliothèques respectent la directive de versioning de Semvar, vous n’avez aucune garantie qu’elles ne se briseront pas lors d’une mise à niveau mineure.)

Ces problèmes sont difficiles à résoudre car vous devez parfois deviner quelle était la dernière version de travail.

En ce qui concerne le test des dernières dépendances de votre projet: C’est ce à quoi npm update est destiné et j’affirme qu’il devrait être exécuté par un développeur, qui exécute également le test localement, qui résout le problème s’ils peuvent survenir, et qui valide ensuite le package-lock.json modifié. (Si une mise à niveau échoue, ils peuvent revenir au dernier package-lock.json en cours d'utilisation.)

En outre, je mets rarement à niveau toutes les dépendances à la fois (car cela pourrait également nécessiter une maintenance supplémentaire), mais je préfère choisir la mise à jour dont j'ai besoin (par exemple, npm update {dependency} ou npm install {dependency}@2.1.3). Ce qui est une autre raison pour laquelle je le verrais comme une étape de maintenance manuelle.

Si vous voulez vraiment l'automatiser, vous pouvez créer un travail pour:

  • dépôt de caisse
  • lancer npm update
  • faire des tests
    • si les tests réussissent, puis valider et pousser dans le référentiel
    • sinon échouer et signaler le problème à résoudre manuellement

C’est quelque chose que je verrais hébergé sur un serveur CI, par exemple. Jenkins, et il ne devrait pas être atteint pour la raison susmentionnée en ajoutant le fichier à la .gitignore.

Ou à citer npm doc :

Il est fortement recommandé de valider le verrou de paquet généré dans le contrôle de source: cela permettra à tous les membres de votre équipe, à vos déploiements, à votre intégration CI/continue et à tous ceux qui exécutent l'installation de npm dans votre source de paquet d'obtenir le même arbre de dépendance. que vous développiez. En outre, les différences de ces modifications sont lisibles par l'homme et vous informeront de toutes les modifications apportées par npm à votre node_modules. Vous pourrez ainsi savoir si des dépendances transitives ont été mises à jour, levées, etc.

Et en ce qui concerne le différence entre npm ci vs npm install :

  • Le projet doit avoir un package-lock.json ou un npm-shrinkwrap.json existant.
  • Si les dépendances dans le verrou de package ne correspondent pas à celles de package.json, npm ci se ferme avec une erreur au lieu de mettre à jour le verrou de package.
  • npm ci ne peut installer que des projets entiers à la fois: aucune dépendance individuelle ne peut être ajoutée avec cette commande.
  • Si un node_modules est déjà présent, il sera automatiquement supprimé avant que npm ci ne commence son installation.
  • Il n'écrira jamais dans package.json ni dans aucun des paquets-verrouillés: les installations sont essentiellement gelées.
29
k0pernikus