Quel est l'intérêt d'avoir résolu l'URL dans package-lock.json?
chaque fois que je génère un fichier package-lock, il y a aussi un bloc "résolu" qui ressemble à ceci:
"resolved": "http://devel.npm.registry:4873/lodash/-/lodash-4.17.5.tgz"
Quel est l'intérêt de cette URL? Plus tard, si j'essaie d'installer des dépendances basées sur ce package-lock, dois-je utiliser le même registre npm? Parce que nous utilisons un registre npm différent pour le développement local et pour les builds de production. Ainsi, lorsque je développe, j'utilise devel.npm.registry, mais l'outil CI utilise production.npm.registry. Selon mes tests, l'URL n'a pas d'importance (j'ai essayé [email protected]). Mais c'est l'implémentation actuelle qui va bientôt changer ou l'URL est-elle intentionnellement ignorée? J'ai le sentiment que certaines des versions précédentes de npm ont effectivement vérifié les URL résolues.
Le documentation n'est pas très utile dans ce cas.
J'ai trouvé quelques articles sur le Web concernant cette question. Suivez les liens:
npm utilise un JSON comme format pour le fichier de verrouillage. La bonne nouvelle est que [email protected] ignore le champ résolu du fichier package-lock.json et revient essentiellement à celui défini dans l'argument .npmrc ou via --registry à l'aide de la CLI au cas où il existe, sinon, il utilisez le défini dans le champ résolu.
https://medium.com/verdaccio/verdaccio-and-deterministic-lock-files-5339d82d611e
Un autre jour, un autre Tweet sur les goodies # npm5.
npm est désormais indépendant du registre que vous avez utilisé pour générer le package-lock.json.
https://Twitter.com/maybekatz/status/862834964932435969
Le but de résoudre dans package-lock.json est de contourner l'étape de résolution de dépendance (récupération des métadonnées) lorsque vous manquez de packages. l'intégrité consiste à vérifier que vous obtenez la même chose. Sans le champ résolu, les installations non mises en cache peuvent se rompre en raison des modifications des métadonnées, et elles seront également beaucoup plus lentes car nous devons effectuer une récupération complète des métadonnées avant de pouvoir réellement télécharger quoi que ce soit.
Notez que package-lock.json ne permet pas de récupérer différents packages à partir de différents registres. Même si vous avez un verrou de package avec différents packages utilisant différents champs résolus, tous les packages seront toujours récupérés à partir de votre paramètre de registre = actuel, dans npmrc. les champs résolus qui ne correspondent pas au registre configuré passeront par la récupération de métadonnées (plus lente) que j'ai mentionnée ci-dessus, mais ne seront toujours récupérés qu'à partir du registre actuel.
https://github.com/npm/npm/issues/16849#issuecomment-312442508