Pourquoi «npm install» réécrit-il package-lock.json?

Je viens récemment de passer à npm @ 5 . J'ai maintenant un fichier package-lock.json avec tout de package.json . Je m'attendrais à ce que, lorsque j'exécute,npm install les versions de dépendance soient extraites du fichier de verrouillage pour déterminer ce qui devrait être installé dans mon répertoire node_modules . Ce qui est étrange, c'est qu'il finit par modifier et réécrire mon fichier package-lock.json .

Par exemple, le fichier de verrouillage a été spécifié pour être à la version 2.1.6 . Ensuite, après la npm installcommande, la version a été changée en 2.4.1 . Cela semble aller à l'encontre de l'objectif global d'un fichier de verrouillage.

Qu'est-ce que je rate? Comment faire pour que npm respecte réellement mon fichier de verrouillage?

Mise à jour 3: Comme le soulignent d'autres réponses, la npm cicommande a été introduite dans npm 5.7.0 comme moyen supplémentaire pour obtenir des builds rapides et reproductibles dans le contexte CI. Voir la documentation et le blog npm pour plus d'informations.

Mise à jour 2: le problème de mise à jour et de clarification de la documentation est le problème GitHub # 18103 .

Mise à jour 1: le comportement décrit ci-dessous a été corrigé dans npm 5.4.2: le comportement actuellement prévu est décrit dans le problème GitHub n ° 17979 .

Réponse originale: Le comportement de a package-lock.jsonété modifié dans npm 5.1.0 comme indiqué dans le numéro # 16866 . Le comportement que vous observez est apparemment prévu par npm à partir de la version 5.1.0.

Cela signifie que cela package.jsonpeut remplacer package-lock.jsonchaque fois qu'une nouvelle version est trouvée pour une dépendance dans package.json. Si vous souhaitez épingler efficacement vos dépendances, vous devez maintenant spécifier les versions sans préfixe, par exemple, vous devez les écrire en tant que 1.2.0au lieu de ~1.2.0ou ^1.2.0. Ensuite, la combinaison de package.jsonet package-lock.jsonproduira des versions reproductibles. Pour être clair:package-lock.json seul ne verrouille plus les dépendances au niveau racine!

Que cette décision de conception soit bonne ou non est discutable, il y a une discussion en cours résultant de cette confusion sur GitHub dans le numéro # 17979 . (À mes yeux, c'est une décision discutable; au moins le nomlock n'est plus vrai.)

Une autre remarque: il existe également une restriction pour les registres qui ne prennent pas en charge les packages immuables, comme lorsque vous extrayez des packages directement depuis GitHub au lieu de npmjs.org. Consultez cette documentation sur les verrous de package pour plus d'explications.

J'ai trouvé qu'il y aura une nouvelle version de NPM 5.7.1 avec la nouvelle commande npm ci, qui installera à partir de package-lock.jsonseulement

La nouvelle commande npm ci s'installe UNIQUEMENT à partir de votre fichier de verrouillage. Si votre package.json et votre fichier de verrouillage ne sont pas synchronisés, il signalera une erreur.

Cela fonctionne en jetant vos node_modules et en les recréant à partir de zéro.

Au-delà de vous garantir que vous n'obtiendrez que ce qui se trouve dans votre fichier de verrouillage, il est également beaucoup plus rapide (2x-10x!) Que l'installation de npm lorsque vous ne démarrez pas avec un node_modules.

Comme vous pouvez le déduire de son nom, nous nous attendons à ce que ce soit une aubaine pour les environnements d'intégration continue. Nous prévoyons également que les personnes qui effectuent des déploiements de production à partir de balises git verront des gains majeurs.

Utilisez le nouveau

npm ci

npm ci promet le plus d'avantages aux grandes équipes. Donner aux développeurs la possibilité de «se déconnecter» sur un verrou de package favorise une collaboration plus efficace entre les grandes équipes, et la possibilité d'installer exactement ce qui se trouve dans un fichier de verrouillage a le potentiel d'économiser des dizaines, voire des centaines d'heures de développement par mois, libérant les équipes pour passer plus de temps à construire et à expédier des choses incroyables.

Présentation npm cipour des versions plus rapides et plus fiables

Réponse courte:

• npm install honore package-lock.json uniquement s'il satisfait aux exigences de package.json.
• S'il ne satisfait pas à ces exigences, les packages sont mis à jour et package-lock est remplacé.
• Si vous échouez plutôt à la compilation, plutôt que de réécrire package-lock lorsque cela se produit, utilisez npm ci.

Voici un scénario qui pourrait expliquer les choses (vérifié avec NPM 6.3.0)

Vous déclarez une dépendance dans package.json comme:

"depA": "^1.0.0"

Ensuite, vous npm installgénérez un package-lock.json avec:

"depA": "1.0.0"

Quelques jours plus tard, une nouvelle version mineure de "depA" est publiée, par exemple "1.1.0", puis ce qui suit est vrai:

npm ci       # respects only package-lock.json and installs 1.0.0

npm install  # also, respects the package-lock version and keeps 1.0.0 installed 
             # (i.e. when package-lock.json exists, it overrules package.json)

Ensuite, vous mettez à jour manuellement votre package.json pour:

"depA": "^1.1.0"

Relancez ensuite:

npm ci      # will try to honor package-lock which says 1.0.0
            # but that does not satisfy package.json requirement of "^1.1.0" 
            # so it would throw an error 

npm install # installs "1.1.0" (as required by the updated package.json)
            # also rewrites package-lock.json version to "1.1.0"
            # (i.e. when package.json is modified, it overrules the package-lock.json)

Utilisez la npm cicommande au lieu denpm install .

"ci" signifie "intégration continue".

Il installera les dépendances du projet basées sur le fichier package-lock.json au lieu des dépendances du fichier lenient package.json.

Il produira des builds identiques à ceux de vos coéquipiers et il est également beaucoup plus rapide.

Vous pouvez en savoir plus à ce sujet dans cet article de blog: https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

À l'avenir, vous pourrez utiliser un --from-lock-fileindicateur (ou similaire) pour installer uniquement à partir dupackage-lock.json sans le modifier.

Cela sera utile pour les environnements CI, etc. où les builds reproductibles sont importants.

Voir https://github.com/npm/npm/issues/18286 pour le suivi de la fonctionnalité.

Il semble que ce problème soit résolu dans npm v5.4.2

https://github.com/npm/npm/issues/17979

(Faites défiler jusqu'au dernier commentaire du fil)

Mise à jour

Actuellement corrigé dans 5.6.0. Il y avait un bogue multiplateforme dans 5.4.2 qui provoquait toujours le problème.

https://github.com/npm/npm/issues/18712

Update 2

Voir ma réponse ici: https://stackoverflow.com/a/53680257/1611058

npm ci est la commande que vous devez utiliser lors de l'installation de projets existants maintenant.

Vous avez probablement quelque chose comme:

"typescript":"~2.1.6"

dans package.jsonlequel npm met à jour la dernière version mineure, dans votre cas,2.4.1

Edit: Question de OP

Mais cela n'explique pas pourquoi "npm install" changerait le fichier de verrouillage. Le fichier de verrouillage n'est-il pas destiné à créer une version reproductible? Si tel est le cas, quelle que soit la valeur semver, il doit toujours utiliser la même version 2.1.6.

Réponse:

Ceci est destiné à verrouiller votre arbre de dépendance complet. Disons qu'il typescript v2.4.1faut widget ~v1.0.0. Lorsque vous installez npm, il prend widget v1.0.0. Plus tard, votre collègue développeur (ou build CI) fait une installation npm et obtient typescript v2.4.1mais widgeta été mis à jour vers widget v1.0.1. Maintenant, votre module de nœud n'est pas synchronisé. C'est ce qui package-lock.jsonempêche.

Ou plus généralement:

Par exemple, considérez

paquet A:

{"nom": "A", "version": "0.1.0", "dépendances": {"B": "<0.1.0"}}

paquet B:

{"nom": "B", "version": "0.0.1", "dépendances": {"C": "<0.1.0"}}

et package C:

{"nom": "C", "version": "0.0.1"}

S'il s'agit des seules versions de A, B et C disponibles dans le registre, une installation npm normale A s'installera:

[email protected] - [email protected] - [email protected]

Cependant, si [email protected] est publié, une nouvelle installation npm A s'installera:

[email protected] - [email protected] - [email protected] en supposant que la nouvelle version n'a pas modifié les dépendances de B. Bien sûr, la nouvelle version de B pourrait inclure une nouvelle version de C et un certain nombre de nouvelles dépendances. Si de tels changements ne sont pas souhaitables, l'auteur de A pourrait spécifier une dépendance à [email protected]. Cependant, si l'auteur de A et l'auteur de B ne sont pas la même personne, il n'y a aucun moyen pour l'auteur de A de dire qu'il ne veut pas insérer de nouvelles versions publiées de C lorsque B n'a pas changé du tout.

OP Question 2: Alors laissez-moi voir si je comprends bien. Ce que vous dites, c'est que le fichier de verrouillage spécifie les versions des dépendances secondaires, mais repose toujours sur la correspondance floue de package.json pour déterminer les dépendances de niveau supérieur. Est-ce exact?

Réponse: Non. Package-lock verrouille la totalité de l'arborescence des packages, y compris les packages racine décrits dans package.json. Si typescriptest verrouillé 2.4.1dans votre package-lock.json, il doit le rester jusqu'à ce qu'il soit modifié. Et disons que la typescriptversion de demain sortira 2.4.2. Si je vérifie votre branche et que je cours npm install, npm respectera le fichier de verrouillage et installera 2.4.1.

Plus sur package-lock.json:

package-lock.json est généré automatiquement pour toutes les opérations où npm modifie l'arborescence node_modules ou package.json. Il décrit l'arborescence exacte qui a été générée, de sorte que les installations suivantes peuvent générer des arborescences identiques, indépendamment des mises à jour de dépendance intermédiaires.

Ce fichier est destiné à être validé dans les référentiels sources et sert à diverses fins:

Décrivez une représentation unique d'une arborescence de dépendances telle que les coéquipiers, les déploiements et l'intégration continue sont garantis pour installer exactement les mêmes dépendances.

Fournir aux utilisateurs la possibilité de "voyager dans le temps" vers les états précédents de node_modules sans avoir à valider le répertoire lui-même.

Pour faciliter une meilleure visibilité des changements d'arbre grâce à des différences de contrôle de source lisibles.

Et optimisez le processus d'installation en permettant à npm d'ignorer les résolutions de métadonnées répétées pour les packages précédemment installés.

https://docs.npmjs.com/files/package-lock.json

Vous devriez probablement utiliser quelque chose comme ça

npm ci

Au lieu de l'utiliser npm install si vous ne souhaitez pas modifier la version de votre package.

Selon la documentation officielle, à la fois npm installet npm ciinstallez les dépendances nécessaires au projet.

La principale différence est, npm installinstalle les packages en prenant packge.jsoncomme référence. Dans le cas où npm ci, il installe les packages en prenant package-lock.jsoncomme référence, en s'assurant à chaque fois que le package exact est installé.

Il y a un problème ouvert pour cela sur leur page github: https://github.com/npm/npm/issues/18712

Ce problème est plus grave lorsque les développeurs utilisent différents systèmes d'exploitation.

EDIT: le nom "lock" est délicat, son NPM essayant de rattraper Yarn. Ce n'est pas un fichier verrouillé. package.jsonest un fichier fixe par l'utilisateur qui, une fois "installé", générera une arborescence de dossiers node_modules et cette arborescence sera alors écrite package-lock.json. Donc, vous voyez, c'est l'inverse - les versions de dépendance seront extraites package.jsoncomme d'habitude et package-lock.jsondevraient être appeléespackage-tree.json

(j'espère que cela a clarifié ma réponse, après tant de votes négatifs)

Une réponse simpliste: package.jsonayez vos dépendances comme d'habitude, alors que package-lock.jsonc'est "un arbre node_modules exact et plus reproductible" (tiré des documents npm lui-même ).

Quant au nom délicat, son NPM essaie de rattraper Yarn.