Dans une équipe, généralement, j'ai été confronté à des conflits de fusion en package-lock.json et ma solution rapide a toujours été de supprimer le fichier et de le régénérer avec npm install . Je n'ai pas sérieusement réfléchi à l'implication de ce correctif car il n'a jamais causé de problème perceptible auparavant.
Y a-t-il un problème avec la suppression du fichier et le fait d'avoir npm le recréer de cette façon au lieu de résoudre les conflits manuellement ?
Oui, cela peut et va affecter tout le projet de manière très négative.
si votre équipe ne court pas npm install après chaque git pull vous utilisez tous des versions différentes des dépendances. Cela se termine donc par "mais ça marche pour moi !" et "je ne comprends pas pourquoi mon code ne fonctionne pas pour vous".
même si toute l'équipe court npm install cela ne signifie pas pour autant que tout va bien. à un moment donné, vous pouvez constater que votre projet se comporte différemment. dans une partie que vous n'avez pas modifiée depuis des années. et après un débogage (probablement assez douloureux), vous découvrirez que c'est parce qu'une dépendance de troisième niveau a été mise à jour pour la prochaine version majeure et que cela a entraîné des changements de rupture.
Conclusion : ne jamais supprimer package-lock.json .
Oui, pour les dépendances de premier niveau si nous les spécifions sans plages (comme "react": "16.12.0" ) nous obtenons les mêmes versions à chaque fois que nous exécutons npm install . Mais nous ne pouvons pas en dire autant des dépendances de plus de 2 niveaux de profondeur (dépendances sur lesquelles nos dépendances reposent), donc package-lock.json est vraiment important pour la stabilité.
Dans votre cas, vous feriez mieux de faire le contraire :
package.json
npm install
Aussi facile qu'il y paraît. La même chose pour yarn - il résout les conflits de lockfile tout seul. La seule exigence ici est de résoudre tous les conflits de package.json au préalable, le cas échéant.
Par docs npm corrigera les conflits de fusion dans package-lock.json pour vous.
Avec l'Approche 2, j'ai remarqué que cela mène facilement à des problèmes où je finis par passer à l'Approche 1 de toute façon, donc je recommanderais d'aller avec l'Approche 1 en premier lieu.
@toni_lehtimaki pourquoi si c'est fondamentalement la même chose ? Si vous optez dans le premier pour rebase sur le courant package-lock.json ou accepter "leur". package-lock.json sur la fusion, ils sont en fait les mêmes. Ou est-ce que je rate quelque chose ici ?
Si j'utilise des versions absolues, je veux dire sans ^ o ~ Le fichier package-lock.json est-il nécessaire ?
Oui, cela peut avoir de mauvais effets secondaires, peut-être pas très souvent mais par exemple vous pouvez avoir dans package.json "moduleX": "^1.0.0" et tu avais l'habitude d'avoir "moduleX": "1.0.0" sur package-lock.json .
En supprimant package-lock.json et en cours d'exécution npm install vous pourriez être en train de mettre à jour la version 1.0.999 de moduleX sans le savoir et peut-être qu'ils ont créé un bogue ou fait un changement cassant (ne suivant pas le versionnement sémantique).
De toute façon, il existe déjà une solution standard pour cela.
package.json
npm install --package-lock-only
https://docs.npmjs.com/cli/v7/configuring-npm/package-locks#resolving-lockfile-conflicts
Si "moduleX" doit être 1.0.0 (et non supérieur), ne faut-il pas spécifier 1.0.0 dans package.json au lieu de ^1.0.0 ?
Je sais que c'est une vieille question mais pour les futurs demandeurs, vous pouvez aussi utiliser npm-merge-driver qui essaie de résoudre automatiquement les problèmes de fusion des fichiers liés à npm.
Il suffit de l'installer globalement npx npm-merge-driver install --global . Vous pouvez en savoir plus à ce sujet ici npm-merge-driver
Edit : Je veux juste avertir les personnes qui sont intéressées par l'utilisation du paquet ci-dessus, que parfois il peut se comporter de manière erratique et être difficile à supprimer. Ainsi, bien qu'il s'agisse d'un outil utile, il nécessite encore un peu de travail.
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.
0 votes
Référez-vous à cette réponse - stackoverflow.com/a/44297998/2251411
0 votes
@john-mutuma Puisque npm a une solution beaucoup plus facile que la réponse acceptée, vous devriez peut-être envisager d'accepter cette (ma) solution ci-dessous à la place :-) Pourquoi perdre du temps sur quelque chose qui peut être corrigé pour vous beaucoup plus facilement :-)