Le PR d'un de mes collègues de travail contient une mise à jour de package-lock.json, qui a ajouté "optional": true :
"minimist": {
"version": "0.0.8",
"bundled": true,
- "dev": true
+ "dev": true,
+ "optional": true
},
"minipass": {Je ne suis pas sûr de ce que cela signifie, même après avoir fait des recherches sur Internet. Quelqu'un pourrait-il m'expliquer ?
De https://docs.npmjs.com/files/package-lock.json#optional :
Si vrai, alors cette dépendance est soit une dépendance optionnelle UNIQUE du module de niveau supérieur, soit une dépendance transitive d'un module. C'est faux pour les dépendances qui sont à la fois une dépendance optionnelle du module de premier niveau et une dépendance transitive d'une dépendance non-optionnelle du module de premier niveau.
Il est possible de fusionner ce changement.
La raison pour laquelle vous voyez ce changement est très probablement parce que npm a légèrement modifié la structure du fichier package-lock.json dans la version 6.6. . Votre compagnon a essentiellement couru npm install avec npm 6.6+ sur un package-lock.json précédemment généré avec npm 6.5-.
Vous devriez pouvoir éviter ce genre de problème en vous assurant que tous les membres de votre équipe utilisent une version récente de npm .
Après qu'un paquet soit retiré des dépendances, ses dépendances sont marquées "optional": true en package-lock.json .
Il est généralement sûr de supprimer ces paquets à la main ou par
$ rm -rf package-lock.json node_modules/
$ npm installToutefois, ce n'est pas sûr à 100 %, car certains paquets seront mis à jour vers des versions plus récentes.
Ref your : "pas sûr à 100%, car certains paquets seront mis à jour vers des versions plus récentes" . L'intérêt d'avoir un gestionnaire de paquets est de pouvoir cloner, installer et avoir un système fonctionnel. Le même système fonctionnel pour tout le monde. Si votre projet dépend d'une version plus ancienne de certains paquets, ce n'est pas parce qu'une version plus ancienne n'est pas disponible. npm i n'a pas été exécuté récemment, vous le faites mal.
@tao considérant la fréquence à laquelle les paquets amont sont publiés avec des bogues et que certains d'entre eux ne tiennent pas compte de SemVer, je souscris à l'opinion selon laquelle l'exécution de npm i n'est pas sûr à 100%.
@villasv le but d'utiliser node est d'avoir une intégration continue. Ce qui veut dire : "vous déployez votre projet sur un serveur, exécutez npm i et ça marche" . Si votre construction dépend des modifications que vous avez apportées à vos paquets après la mise en place de l'outil npm i vous développez à peu près comme à la fin des années 80 : vous devez télécharger la copie exacte de la machine locale sur le serveur pour que cela fonctionne. Dans ce cas, vous ne devriez pas vous embêter à utiliser node du tout. Vous pouvez simplement placer tous les actifs nécessaires du fournisseur dans un dossier et les charger à partir de là.
L'une des raisons serait :
Certains paquets npm peuvent nécessiter des paquets dépendants (par exemple minimist) pour fonctionner sur différents systèmes d'exploitation. NPM marque ces paquets comme optionnels lors de l'installation de npm, s'ils ne sont pas nécessaires en fonction du système d'exploitation que vous utilisez.
Veuillez vérifier le problème ci-dessous :
Problème ouvert : package-lock.json et paquets optionnels : https://github.com/npm/npm/issues/17722
J'espère que cela vous aidera.
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.
7 votes
Ne postez JAMAIS d'images de code, d'erreurs ou de résultats ! stackoverflow.com/help/how-to-ask