Quel est l'intérêt d'avoir une "version compatible" (^version) déclarée dans package.json si package-lock.json la verrouille ?

Question

Je connais les principaux avantages de package-lock.json et je suis d'accord avec ça. Il ne verrouille pas seulement la version téléchargée dans la dernière installation, mais aussi l'uri... et c'est nécessaire dans la plupart des cas pour pouvoir répliquer le projet le plus similaire possible.

Mais une chose qui me semble bizarre est que package.json a la particularité de déclarer une dépendance comme dependency: ^1.0.0 ce qui devrait permettre à npm de télécharger la version la plus récente et la plus compatible de ce paquet dans chaque installation.

Je travaille sur un projet pour lequel j'ai vraiment besoin de ça. Sinon, à chaque fois que ma dépendance publiera un correctif, elle sera obligée de faire un nouveau commit mettant à jour package.json en changeant seulement la version, donc mon pipeline peut aussi écraser package-lock.json .

En bref, il semble que si package.json utilise une fonction... package-lock.json empêche celui-là.

Est-ce que j'ai manqué quelque chose ?

Answer 1

Le point de package-lock.json est de représenter fidèlement l'arbre tel qu'il existe réellement à un moment donné, de sorte que quelqu'un clonant le projet obtienne exactement le même arbre que toi.

Si vous voulez mettre à niveau cette dépendance vers une version plus récente, il suffit d'utiliser npm update et ensuite valider la mise à jour package-lock.json . Les autres membres de votre équipe recevront cette mise à jour dans le cadre du processus normal d'acquisition de la dernière version.

Plus dans le Page de npmjs.com sur les verrous de paquets .

Considérons un scénario dans lequel vous et moi sommes dans une équipe et notre projet utilise nifty-lib con package.json en disant "nifty-lib": "^0.4.0" et nous ne partageons pas package-lock.json . Peut-être que je travaille sur le projet depuis deux mois de plus que vous et que j'ai nifty-lib v0.4.0 quand je l'ai installé. Mais lorsque vous l'avez récupéré et installé, vous avez obtenu la v0.4.1 (une mise à jour de correction de bogues qui, malheureusement, a introduit un nouveau bogue). À un moment donné, vous remarquez ce qui semble être un bogue dans notre projet, mais je ne peux pas le reproduire. Nous tournons en rond pendant un moment en essayant de comprendre pourquoi cela arrive à vous et pas à moi. Finalement, nous nous rendons compte que c'est parce qu'il s'agit en fait d'un bug de nifty-lib qu'ils ont introduit dans la v0.4.1. Avec un peu de chance, nous obtiendrons alors la 0.4.2 ou quelque chose comme ça (ou s'il n'y en a pas, nous corrigeons le bogue et faisons un PR, tout en revenant à la 0.4.0 pour l'ensemble du projet).

Si nous avions partagé package-lock.json nous n'aurions pas tourné sur place en nous demandant pourquoi le problème est arrivé à vous et pas à moi, parce que vous auriez eu la même version de nifty-lib comme moi. Dans le cadre de notre cycle normal, nous ferions npm update périodiquement, et si un nouveau bogue apparaissait dans nos tests, nous saurions, grâce à l'historique des livraisons, que c'était à cause d'un bogue dans une dépendance.

Maintenant, pour "moi" et "vous", lisez "dev" et "production". :-)

C'est pourquoi package-lock.json verrouille la version, mais package.json vous permet de dire "ceci ou mieux". package-lock.json permet de garder votre équipe unifiée sur les versions, mais vous pouvez intentionnellement mettre à jour avec npm update qui apparaît dans l'historique des livraisons, ce qui vous permet de suivre les régressions.

Answer 2

Comme je l'ai mentionné dans un commentaire ci-dessus, la réponse courte est qu'il fait update l'intégration de vos dépendances.

Cependant, une autre façon que j'aime de penser aux deux fichiers est : paquet.json est le fichier que l'humain lit, tandis que paquet-lock.json est le fichier que l'ordinateur lit.

NPM est un gestionnaire de paquets et de dépendances. Ainsi, dans votre paquet.json vous écrivez "ces bibliothèques sont nécessaires pour que ma bibliothèque fonctionne". En tant que fonctionnalité vous disposez d'un éventail de versions pour lesquelles vous pouvez répertorier une dépendance. Ceci est utile lorsque vous exécutez npm update sur un paquet spécifique. Il cherchera à voir quelle est la dernière version qui correspond à votre *package.json**, et mettra à jour votre fichier de verrouillage.

Le site paquet-lock.json lockfile est utile parce qu'il décrit de manière détaillée ce qu'est votre node_modules/ afin qu'il puisse être recréé avec précision lorsque quelqu'un d'autre installera votre bibliothèque. De plus, comme ce fichier est généré automatiquement, vous n'avez pas à vous soucier de sa maintenance.

Bien sûr, tout ceci se trouve être la manière dont NPM (et inversement la manière dont le plus paquet gestionnaires ) s'en occupe. C'est-à-dire qu'il n'y a pas de raison technique pour laquelle nous ne pourrions pas avoir un seul fichier pour décrire à la fois la gamme de versions qui serait autorisée lors de l'exécution des mises à jour, et une partie verbeuse du fichier de verrouillage qui épingle les versions pour permettre un arbre de dépendance recréable.

En fait, il ne s'agit que d'une commodité. Vous avez un fichier pour lister succinctement les dépendances dont vos projets ont besoin. Il est lisible et facile à mettre à jour. L'autre fichier, le lockfile, est automatiquement généré et assure que chaque npm install vous donne exactement la même node_modules/ comme avant.