Yarn: faire `--pure-lockfile` par défaut pour `installer`

Je suis d'accord. Il devrait y avoir une discussion sur la raison yarn install laquelle

Il existe un cas pour yarn install créer un fichier de verrouillage s'il n'y en a pas, c'est-à-dire lorsque quelqu'un convertit un projet pour utiliser yarn , mais la raison de toujours l'écrire n'est pas claire. Je suis d'accord avec l'opinion de @bestander selon laquelle seules les actions de mutation devraient mettre à jour le fichier de verrouillage par défaut, c'est- add/upgrade/remove dire

Devrait-il y avoir un moyen de modifier le fichier de verrouillage sans add/remove/upgrade ex : dans le scénario où vous mettez à niveau Yarn et qu'il utilise une nouvelle version du fichier de verrouillage ?

Je suppose que l'option pourrait être inversée

yarn install --save-lockfile

Le 17 octobre 2016 à 18h53, James Ide [email protected] a écrit :

Devrait-il y avoir un moyen de modifier le fichier de verrouillage sans ajouter/supprimer/mettre à niveau
ex : dans le scénario où vous mettez à niveau Yarn et qu'il utilise un nouveau fichier de verrouillage
version?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/570#issuecomment -254282256, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ACBdWJLpdvqiwcBwqE4KB3x3f4oCn_nVks5q07YYgaJpZM4KSlSw
.

Je suis également confus par cela. Quelle est la raison du comportement par défaut actuel ?

Afaik, il n'y avait pas de bonnes raisons pour le comportement par défaut.
L'idée, je suppose, est de garder les fichiers de verrouillage des gens "permanents".

BTW PR est le bienvenu

Je pense que la raison en est que le fil a été conçu à l'origine avec une seule commande install qui a été divisée en install/add/upgrade

Donc pour vérifier si j'ai bien compris :

yarn installe toutes les dépendances et modifie également le fichier de verrouillage. Sur un serveur CI, vous devriez utiliser yarn install --pure-lockfile ?
Pourquoi le fichier de verrouillage est-il modifié lors d'une installation ? Puisque vous ne mettez rien à niveau... Yarn devrait simplement installer les packages comme décrit dans le fichier de verrouillage, n'est-ce pas ?

Merci pour l'explication!

Le problème est que si le fichier de verrouillage est pur par défaut, les gens vont oublier de le mettre à jour car il s'agirait d'une commande distincte.

@kittens Le fichier de verrouillage ne devrait-il pas être mis à jour uniquement lors de l'ajout/suppression/mise à niveau de packages ? Ceux-ci doivent toujours mettre à niveau le fichier de verrouillage, ainsi qu'une installation initiale.

Le problème est que si le fichier de verrouillage est pur par défaut, les gens vont oublier de le mettre à jour car ce serait une commande distincte

Ce problème dépend de ce que vous considérez comme l'objectif principal d'un gestionnaire de paquets.

À mon avis, l'un des rôles remplis par un gestionnaire de packages est de faciliter au maximum le démarrage du développement d'un projet. Un simple yarn install devrait obtenir tous les packages dont vous avez besoin pour commencer à développer, sans aucune confusion.

Avec npm nombreux développeurs ont rejoint un projet, seulement pour découvrir qu'un projet ne fonctionnait pas sur leur machine. Ces instances se sont produites en raison de dépendances transitoires faisant passer les versions aux versions avec des modifications de rupture ou tout simplement ne suivant pas sever. J'avais espéré que yarn résoudrait ces problèmes, mais si le point à retenir est que tous les développeurs d'un projet doivent exécuter yarn install --pure-lockfile pour être sûr à 100% que le projet va se construire, alors ce n'est pas le cas. l'affaire.

Un autre rôle d'un gestionnaire de packages est de donner aux projets le contrôle de leurs dépendances. S'il est rendu pur par défaut, les développeurs peuvent consulter yarn outdated pour voir les versions obsolètes, puis consulter les notes de modification, en évitant toute modification de rupture. Cela donnerait aux développeurs le contrôle total de ne modifier que les versions dans un délai de publication donné au lieu d'interdire aux développeurs de faire git commit -a pour éviter les commits accidentels de fichiers de verrouillage.

Je suis d'accord avec tout ce que dit

Nous avons totalement surpris en cassant la construction après avoir commencé à utiliser yarn pendant quelques jours. Honnêtement, je pensais que --pure-lockfile était le comportement par défaut après avoir lu une grande partie de la documentation et sur la façon dont c'est mieux que npm avec du film rétractable. S'il vous plaît faire par défaut :)

@ide Imaginez un scénario où quelqu'un utilise simplement npm et met package.json jour yarn.lock va-t-il être mis à jour ?

Quelqu'un peut-il écrire les scénarios qui conduisent à la modification inattendue du fichier de verrouillage ? Ce changement est sérieux et fait du fichier de verrouillage un citoyen de deuxième classe en exigeant que les mises à jour soient explicites, ce qui signifie beaucoup de temps système pour se souvenir des opérations qui entraînent sa mise à jour, etc.

Plus d'informations sur ce qui précède : notre version a coffeescript de Github en tant que sous-dépendance. coffeescript a poussé quelques commits et nous avons obtenu un yarn.lock modifié dans notre processus de construction en exécutant seulement yarn install :

diff --git a/foo/yarn.lock b/foo/yarn.lock
index ec667fa..bb1f6ae 100644
--- a/foo/yarn.lock
+++ b/foo/yarn.lock
@@ -930,9 +930,9 @@ code-point-at@^1.0.0:
   version "1.6.3"
   resolved "https://registry.yarnpkg.com/coffee-script/-/coffee-script-1.6.3.tgz#6355d32cf1b04cdff6b484e5e711782b2f0c39be"

-"coffee-script<strong i="8">@github</strong>:jashkenas/coffeescript":
+coffee-script@jashkenas/coffeescript:
   version "1.11.1"
-  resolved "https://codeload.github.com/jashkenas/coffeescript/tar.gz/887052de079b2f0af9f080031a00bb7544eaca08"
+  resolved "https://codeload.github.com/jashkenas/coffeescript/tar.gz/0d132318ce8f7116a436d97db1f2a5c8b1dedf28"

 [email protected]:
   version "0.3.0"

Quelqu'un peut-il écrire les scénarios qui conduisent à la modification inattendue du fichier de verrouillage ? Ce changement est sérieux et fait du fichier de verrouillage un citoyen de deuxième classe en exigeant que les mises à jour soient explicites, ce qui signifie beaucoup de temps système pour se souvenir des opérations qui entraînent sa mise à jour, etc.

Je perçois yarn install comme une commande qui construit des node_modules pour moi.
C'est l'opposé de yarn add et yarn remove qui modifient package.json, fil.lock et cleanup node_modules.
Par opposition à add et remove Je cours install 100 fois plus souvent surtout en IC où je ne m'attends jamais à avoir des effets secondaires.

Exemples où je ne m'attends pas à ce que les choses changent :

1. Je suis sur Yarn 0.15.0, mes coéquipiers sont sur Yarn 0.16.0.
   Étant donné que 0.16.0 a ajouté des espaces entre les entrées dans wire.lock chaque fois que j'exécute yarn install contre thread.lock qui a été généré par mes coéquipiers, j'obtiens un fichier thread.lock modifié que je dois me rappeler de ne pas valider.
   Et vice versa.
2. Mes autres outils de construction dépendent de fil.lock en tant que "source de vérité" de l'état node_modules. Si cela change de manière inattendue, j'obtiendrai un non-déterminisme dans mes builds

@chatons

Le problème est que si le fichier de verrouillage est pur par défaut, les gens vont oublier de le mettre à jour car il s'agirait d'une commande distincte.

Imaginez un scénario où quelqu'un utilise simplement npm et met à jour package.json, comment wire.lock va-t-il être mis à jour ?

Si nous supposons que yarn install ne doit pas mettre yarn.lock jour yarn.lock n'est pas synchronisé avec package.json pour mettre en évidence le fait qu'un yarn install --save-lockfile est nécessaire pour tout synchroniser.

L'installation de +1 fil ne doit pas muter le fil.lock

1. Le débogueur est une application oss. Nous voulons que les contributeurs puissent installer le fil et obtenir les _bonnes_ versions. Nous avons eu des gens qui ont installé npm et qui ont dit que c'était en panne à cause des propriétés transitives. Avec l'installation de fil, les contributeurs fil installent et ne savent pas quoi faire avec les changements de fil.

Je ne suis pas inquiet de la mise à jour du fichier de verrouillage. Idéalement, greenkeeper le ferait lorsque deps change et nous pourrions alors fusionner le changement de fichier de verrouillage.

Je souhaite mettre à jour ce problème avec les réflexions actuelles à ce sujet. @kittens et moi pensons tous les deux que --pure-lockfile ne devrait _pas_ être la valeur par défaut pour plusieurs raisons.

Cela commence par la façon dont les gens ajoutent/suppriment/mettent à jour des dépendances. Bien qu'il existe des commandes pour cela, il est courant de mettre à jour manuellement le package.json à la main ou à l'aide d'un autre outil comme Lerna .

Une fois que vous avez modifié manuellement le package.json l'attente dans Yarn et npm est que lorsque vous exécutez une autre installation, il se synchronise_ avec le package.json . En ce sens, yarn install pourrait presque être renommé yarn sync .

En ce qui concerne la synchronisation, lorsque vous exécutez une installation avec de nouvelles dépendances, vous vous attendez à ce que le répertoire node_modules reflète ces modifications. Étant donné que yarn.lock agit comme un assistant pour node_modules vous devez vous attendre à ce qu'il reste synchronisé de la même manière.

Votre package.json est la source ultime de vérité, c'est votre interface avec le fil, c'est votre configuration et c'est la seule chose dont vous devriez vous préoccuper. Dans un monde idéal, vous engagez simplement vos yarn.lock et ne devez plus jamais y penser.

En passant, je pense que de nombreuses personnes qui expriment leur soutien à ce problème sont confuses quant à ce qui est réellement discuté ici.

L'utilisation de --pure-lockfile par défaut ne signifie pas que Yarn ne produit pas de résultats cohérents et fiables. Le même package.json se traduira par le même yarn.lock qui se traduira par le même node_modules 100% du temps.

Lorsque vous mettez à jour votre package.json votre fichier yarn.lock met à jour, puis vos mises à jour node_modules . C'est un ordre très naturel des choses et nous devrions le garder ainsi

En ce qui concerne CI, la possibilité d'obtenir différentes dépendances lorsque vous avez mis à jour votre package.json mais que vous n'avez pas exécuté yarn install pour synchroniser tout ce que je suis sûr que quelqu'un évoquera (bien que je ne vois pas comme un problème)-- moi-même et d'autres avons parlé à divers outils CI sur l'intégration de Yarn, nous pouvons facilement les pousser à utiliser --pure-lockfile par défaut si les gens voient cela comme un gros problème.

Si nous devions faire ce changement, cela aurait un impact négatif beaucoup plus souvent lors du changement de dépendances. Pour les raisons que j'ai énumérées, je dis que nous devrions clore cette question.

@thejameskyle , j'apprécierais si vous pouviez clarifier quelque chose :

1. Un développeur a un package.json qui contient une dépendance "foo": "^1.0.0"
2. Le développeur exécute yarn install . Le package foo est actuellement la version 1.0.0 , il crée donc un fichier yarn.lock qui verrouille [email protected]
3. Le développeur ajoute yarn.lock à Git.
4. Le développeur exécute des tests unitaires sur sa copie locale du référentiel, tout fonctionne bien.
5. Le développeur pousse son repo vers CI (par exemple Travis).
6. CI exécute yarn install , mais foo est maintenant mis à jour vers la version 1.1.0 , donc Yarn installe [email protected] et écrase yarn.lock avec la nouvelle version de foo
7. Le CI s'arrête car foo subi un changement majeur dans la version 1.1.0

Voici une situation similaire :

1. Un développeur a un package.json qui contient une dépendance "foo": "^1.0.0" , qui est verrouillée en tant que [email protected] , et yarn.lock est enregistré dans Git.
2. Les tests unitaires fonctionnent correctement sur la copie locale du dépôt du développeur.
3. Un contributeur clone le repo dans le but de faire une modification + pull request.
4. Lorsque le contributeur exécute yarn install il obtient la version [email protected] qui entraîne la mise à jour de yarn.lock .
5. Maintenant, la version du contributeur est cassée car foo subi un changement majeur dans la version 1.1.0

Je pense que c'est le genre de situations qui inquiètent la plupart des gens.

Donc, si vous pouviez préciser que le comportement actuel de yarn install n'a pas les problèmes ci-dessus, je pense que cela éliminerait la plupart de nos craintes. :+1:

Aucune de ces situations ne s'applique. Ce n'est pas parce qu'une dépendance a été mise à jour que vous l'obtiendrez, uniquement si vous avez apporté des modifications à votre package.json .

Je vais simplement clore ce sujet car il semble vraiment que ce soit la seule préoccupation des gens, ce qui, comme je l'ai dit, n'est pas un scénario réel. Ce problème cause probablement plus de confusion.

Mais il a le mauvais comportement si une dépendance est installée à partir de github, comme je l'ai signalé ci-dessus

@adamchainz Cela devrait être corrigé séparément, nous pouvons facilement le verrouiller au commit

Aucune de ces situations ne s'applique. Ce n'est pas parce qu'une dépendance a été mise à jour que vous l'obtiendrez, uniquement si vous avez apporté des modifications à votre package.json .

@thejameskyle : Je ne suis pas sûr de comprendre pourquoi ce n'est pas un vrai scénario. Pourriez-vous s'il vous plaît élaborer?

Imaginez une fonction memoize où l'entrée est un package.json et la sortie est le yarn.lock .

1. La première fois que vous passez un package.json il crée un yarn.lock et met en cache le résultat.
2. La prochaine fois que vous exécuterez _ce même_ package.json le résultat sera exactement le même car il est mis en cache.
3. Lorsque vous modifiez le package.json vous avez invalidé le cache et maintenant le yarn.lock sera recalculé.

Ce dont nous parlons en ce moment, c'est de se débarrasser de # 3 et de traiter à la place yarn.lock comme s'il n'avait pas été invalidé par le package.json modifié. Ce qui serait vraiment bizarre pour une fonction memoize et ce serait un comportement vraiment bizarre pour Yarn.

Ce qui arrive à un paquet en termes de commits et de nouvelles versions _devrait_ être sans importance (si nous avons un bogue avec les commits git, nous devrions le corriger séparément, mais ce n'est pas lié à ce problème).

C'est plus complexe que je ne l'avais imaginé (chaque version de package est effectivement "mémorisée" individuellement, changer la version d'un package n'invalide pas le reste), mais j'espère que maintenant tout le monde comprendra le point.

@thejameskyle : Par souci de clarté (et de curiosité), disons que j'ai un projet avec un fichier yarn.lock , et que quelqu'un retire le référentiel. Sans exécuter yarn install ou npm install , cette personne ajoute une nouvelle dépendance au fichier package.json puis exécute yarn install . Le fichier yarn.lock existant sera-t-il complètement ignoré dans ce cas ?

Il se passe un tas de choses différentes ici que je voulais essayer de démêler (sans jeu de mots).

Tout d'abord, les gens ont soulevé un certain nombre d'exigences différentes qui, je pense, ne prêtent pas à controverse (et qui rendent certains des bugs de comportement existants, auxquels je reviendrai bientôt).

Du rapport de bogue original.

La cohérence est perdue lorsque le fichier de verrouillage est modifié en fonction de l'environnement (version de fil actuellement installée).
Quel est le comportement attendu ?
N'écrivez pas fil.lock ou package.json lors de l'installation de fil.
Pour mettre à jour laine.lock, utilisez la mise à niveau de laine

Pour être plus précis, les sémantiques attendues, à mon avis, sont :

• si package.json n'a pas changé depuis la dernière fois que yarn.lock changé, yarn.lock est la source de vérité et ne doit pas être mis à jour.
• si package.json a changé depuis la dernière fois, yarn.lock changé, mettez yarn.lock jour package.json et mettez node_modules jour
• si yarn update est exécuté, résolvez toutes les dépendances et obtenez la dernière version de tout ce qui satisfait le package.json .

Cela signifie que lorsqu'un dépôt est cloné pour la première fois sur une machine , si le yarn.lock été archivé, fil doit toujours le traiter comme la source de vérité, ne pas générer de mises à jour du yarn.lock , et sauter directement à l'étape d'extraction.

Dans la mesure où ce n'est pas le comportement actuel de laine, je pense que ce serait un bug.

@esphen a écrit :

Je suis d'accord. Il devrait y avoir une discussion sur la raison pour laquelle wire install écrit un fichier de verrouillage par défaut en premier lieu, car cela semble être en contradiction avec l'ensemble du concept de fichier de verrouillage. Pourquoi avoir un fichier de verrouillage s'il ne verrouille pas les versions par défaut ?

Je pense que ce que cela essaie de dire, c'est que fil ne doit pas écrire un nouveau fichier de verrouillage si celui qui existe est toujours à jour. Je suis d'accord avec ça.

Je suis d'accord avec l'opinion de @bestander selon laquelle seules les actions de mutation devraient mettre à jour le fichier de verrouillage par défaut, c'est-à-dire ajouter/mettre à niveau/supprimer.

Le principal problème ici est de savoir si une modification du package.json devrait entraîner la mise yarn.lock du package.json n'est pas satisfait par le yarn.lock , il doit mettre à jour le yarn.lock .

Un invariant important des systèmes de fichiers de verrouillage comme le fil est que, en utilisant le flux de travail normal, les développeurs peuvent être sûrs que les packages qui sont réellement utilisés lorsqu'ils exécutent leur application correspondent aux versions spécifiées dans leur package.json . Si le package.json est autorisé à se désynchroniser avec le yarn.lock , ce ne sera pas vrai, et le seul moyen de le savoir sera que les lecteurs humains lisent attentivement le yarn.lock .

La meilleure façon pour la plupart des utilisateurs de penser au fichier de verrouillage est qu'il s'agit d'un artefact du fil en cours d'exécution qui représente les versions précises de tous les packages qui ont été utilisés pour le package.json actuel. En l'enregistrant, les autres collaborateurs, CI et le code de production sont assurés d'utiliser ces mêmes versions.

@Guuz a dit :

Donc pour vérifier si j'ai bien compris :
fil installe toutes les dépendances et modifie également le fichier de verrouillage. Sur un serveur CI, vous devez utiliser wire install --pure-lockfile ?

Cette question fait écho à un sentiment que quelques personnes ont exprimé dans ce fil.

Cargo a un drapeau --locked qui dit "si le package.json n'est pas satisfait par le yarn.lock , c'est une erreur grave". Bundler a un indicateur similaire ( --frozen ), qui a été ajouté lorsque Heroku a adopté Bundler, pour donner aux gens une erreur matérielle s'ils apportaient des modifications locales à leur Gemfile et oubliaient de vérifier le Gemfile.lock .

L'idée est que pendant votre développement normal, vous voudriez pouvoir apporter des modifications au package.json et faire en sorte que le fil s'assure que le yarn.lock reste synchronisé (encore une fois, pour s'assurer que les versions spécifiées dans package.json correspondent toujours à ce qui est utilisé dans la pratique).

Mais lors du déploiement, c'est pratiquement toujours une erreur d'avoir divergé, car cela signifie que vous avez modifié package.json , exécuté une commande locale yarn et oublié d'enregistrer yarn.lock . Cela signifie que les versions de votre package.json ne correspondent pas aux versions réelles utilisées lors de l'exécution de l'application , ce qui, selon nous, viole un invariant fondamental de laine.

@esphen a dit :

À mon avis, l'un des rôles remplis par un gestionnaire de packages est de faciliter au maximum le démarrage du développement d'un projet. Une simple installation de fil devrait obtenir tous les packages dont vous avez besoin pour commencer à développer, sans aucune confusion.

Je pense que ce n'est pas controversé.

Avec npm, de nombreux développeurs ont rejoint un projet pour découvrir qu'un projet ne fonctionnait pas sur leur machine. Ces instances se sont produites en raison de dépendances transitoires faisant passer les versions aux versions avec des modifications de rupture ou tout simplement ne suivant pas sever. J'avais espéré que fil résoudrait ces problèmes, mais si le point à retenir est que tous les développeurs d'un projet doivent exécuter wire install --pure-lockfile pour être sûr à 100% que le projet va se construire, alors ce n'est pas le cas.

L'exécution de yarn install --pure-lockfile signifie que le fichier de verrouillage sera respecté même si les versions à l'intérieur du fichier de verrouillage sont en conflit avec les versions spécifiées dans le package.json . Cela ne devrait se produire que si un développeur oublie d'enregistrer son yarn.lock après avoir modifié le package.json .

Un autre rôle d'un gestionnaire de packages est de donner aux projets le contrôle de leurs dépendances. S'il est rendu pur par défaut, les développeurs peuvent consulter le fil obsolète pour voir les versions obsolètes, puis examiner les notes de modification, en évitant toute modification avec rupture. Cela donnerait aux développeurs le contrôle total de ne modifier que les versions dans un délai de publication donné au lieu d'interdire aux développeurs de faire git commit -a pour éviter les commits accidentels de fichiers de verrouillage.

Si le package.json n'a pas changé, à mon avis c'est un bug si yarn.lock est mis à jour. Au moins un cas de bogue semble être dans le rapport d'origine :

lockfile est modifié en fonction de l'environnement (version de fil actuellement installée).

Je pense que c'est une erreur et qu'il faut la corriger.

Plus tard dans le fil, @thejameskyle a déclaré :

Imaginez une fonction memoize où l'entrée est un package.json et la sortie est le fil.lock.

C'est exactement le bon modèle mental, à mon avis (" yarn.lock peut changer si et seulement si package.json changé"), et si l'abstraction fuit, nous devrions le réparer.

@adamchainz a dit :

Plus d'informations sur ce qui précède : notre version a coffeescript de Github en tant que sous-dépendance. coffeescript a poussé quelques commits et nous avons obtenu un fil.lock modifié dans notre processus de construction en exécutant juste l'installation de fil

et ensuite:

Mais il a le mauvais comportement si une dépendance est installée à partir de github, comme je l'ai signalé ci-dessus

Le problème ici est que fil ne traite pas le git sha comme faisant partie de la version verrouillée des dépendances git. Cargo et Bundler ont tous deux le concept d'une version « précise » qui est sérialisée dans le fichier de verrouillage ; pour les sources git, la version "précise" est le SHA. Ensuite, lorsque vous créez un nouveau clone avec seulement package.json et yarn.lock et exécutez yarn , toutes les informations nécessaires pour obtenir précisément le code dont vous avez besoin sont là.

Je dois avouer que j'ai raté cette interaction lors de l'examen du code git d'origine ; il y a un certain suivi SHA dans le code, mais yarn install ne garantit pas que le graphe de dépendance hydraté le respecte.

TL;DR

Je suis d'accord avec @thejameskyle et @kittens que yarn.lock doit être synchronisé avec package.json automatiquement, car je pense que les utilisateurs devraient pouvoir supposer que les versions spécifiées dans leur package.json aligner avec ce qui est utilisé lorsque leur application est exécutée.

Cependant, il semble y avoir quelques bogues qui provoquent un taux de désabonnement inapproprié dans le yarn.lock même lorsque le package.json n'a pas changé :

• les modifications apportées à la version du fil sur les machines mettent à jour le fichier de verrouillage
• les dépendances git sont mises à jour même si package.json n'a pas été mis à jour, ce qui met alors à jour le fichier de verrouillage

Nous devrions également considérer quelque chose comme le drapeau --locked Cargo, que vous pouvez utiliser dans CI pour faire échouer rapidement la construction si un développeur met à jour le package.json et oublie d'enregistrer le yarn.lock .

@thejameskyle Merci ! :heart: Je suis d'accord avec vous et @kittens que yarn.lock devrait être mis à jour après avoir modifié package.json

@wycats Un article très complet et perspicace comme d'habitude. :+1: Je suis d'accord avec toi, et j'aime aussi l'idée d'un drapeau --locked (ou similaire). Nous devrions créer un nouveau problème à ce sujet.

Créé #1568 pour suivre le problème git SHA

@wycats , merci pour cet aperçu très éclairant et très instructif !

Cela signifie que lorsqu'un dépôt est cloné pour la première fois sur une machine, si le fil.lock a été archivé, fil doit toujours le traiter comme la source de vérité, ne pas générer de mises à jour du fil.lock et passer directement à l'étape de récupération.
Dans la mesure où ce n'est pas le comportement actuel de laine, je pense que ce serait un bug.

C'est exactement le scénario pour lequel cette question a été ouverte.
Nous avons quelques versions actives de Yarn dans l'entreprise et à notre échelle, je ne pense pas que nous pourrons faire des mises à jour atomiques partout.
Les constructions sur fil 0.13, 0.14 et 0.15 ont introduit de légères variations dans les fichiers fil.lock même si package.json était synchronisé.
Cela a causé quelques problèmes, par exemple les builds Buck ont ​​été ralentis car les changements dans l'arborescence source invalident les caches.
Cela m'a causé, à moi et à quelques équipes, quelques heures de travail.

@thejameskyle , merci d'avoir partagé votre opinion.
Je ne considérais pas que le scénario de package.json désynchronisé avec fil.lock était juste. Et vous avez un point valable.

Cependant, comme l' a souligné
Il est important de résoudre ce problème pour avoir des versions valides et je rouvrirai le problème avec l'intention de trouver une solution qui satisfasse toutes les parties intéressées.

@wycats

Pour être plus précis, les sémantiques attendues, à mon avis, sont :

• si package.json n'a pas changé depuis la dernière fois que yarn.lock changé, yarn.lock est la source de vérité et ne doit pas être mis à jour.
• si package.json a changé depuis la dernière fois, yarn.lock changé, mettez yarn.lock jour package.json et mettez node_modules jour
• si yarn update est exécuté, résolvez toutes les dépendances et obtenez la dernière version de tout ce qui satisfait le package.json .

Cela signifie que lorsqu'un dépôt est cloné pour la première fois sur une machine , si le yarn.lock été archivé, fil doit toujours le traiter comme la source de vérité, ne pas générer de mises à jour du yarn.lock , et sauter directement à l'étape d'extraction.

Ce sont les sémantiques que nous suivons que j'ai ajoutées en #364.

@bestander Vous avez été impliqué dans les relations publiques (#364) qui ont mis en place ces heuristiques. Quels changements supplémentaires proposez-vous?

Ce problème est extrêmement vaste et nous avons déjà convenu que --pure-lockfile ne sera pas la valeur par défaut et nous suivrons les heuristiques décrites par @wycats. Si ce problème doit rester ouvert, le titre doit refléter le problème actuel avec ce comportement.

@kittens sonne bien, je mettrai à jour le problème.
Ou peut-être devrais-je en ouvrir un nouveau lié à l'installation en changeant le fichier de verrouillage lorsque package.json n'a pas changé

Pouvons-nous passer à un nouveau problème? Ces commentaires ici peuvent simplement être conservés en tant qu'archive

Ça a l' air bien,

Création du nouveau numéro ciblé https://github.com/yarnpkg/yarn/issues/1576

il serait intéressant d'avoir une option pour faire échouer yarn install si le package dans package.json n'est pas dans fil.lock, c'est-à-dire. échouer si un paquet n'est pas verrouillé

Ajout d'une précision qui était encore ambiguë pour moi après avoir lu ce qui précède :

tldr; exécutez yarn install , une dépendance de yarn.lock entrée est modifiée seulement quand il est associé package.json est modifié l' Les modifications non liées dans package.json ne mettront pas à jour un package vers la dernière version compatible avec son serveur package.json inchangé.

Sur la base de certaines des formulations ci-dessus, il semblait que yarn.lock était mis en cache sur un hachage package.json , et donc il semblait que yarn.lock serait écrit (mis à jour / cache invalidé ) sur toute modification de package.json , ce qui serait problématique car une modification non liée (c'est-à-dire une mise à jour vers "description" ou une autre dépendance) pourrait entraîner la mise à jour de la version yarn.lock cette dépendance une version plus récente dans le même serveur package.json existant.

Cependant, j'ai vérifié que l'entrée yarn.lock un package n'est écrite que lorsque le package.json semver correspondant est mis à jour (même si le nouveau semver est compatible avec la version yarn.lock existante, et par conséquent, ne nécessiterait pas autrement une mise à jour de version).

Par exemple,

• Dites yarn add lodash@^4.17.1 installe [email protected]
• Plus tard, [email protected] est disponible.
• le fil continuera à installer [email protected]
• À moins que/jusqu'à ce que la version de lodash soit modifiée dans package.json (ou que l'ajout/la mise à niveau/la suppression de fil soit exécuté spécifiquement contre lodash).

Fil d'Ariane #1576

D'ailleurs, si vous êtes prêt à contribuer aux documents avec de petits articles comme celui-ci, ce serait formidable pour la communauté.
L'équipe de base est toute occupée à résoudre les problèmes et à ajouter de nouvelles fonctionnalités et il est attendu et apprécié si la communauté aide à maintenir la documentation

@CrabDude merci d'avoir partagé vos éclaircissements.

Voulez-vous dire - dans votre exemple ci-dessus - que seuls lodash et ses propres dépendances verront leurs versions de verrouillage mises à jour dans yarn.lock ? Par exemple, même si une autre dépendance pouvait avoir une nouvelle version de verrouillage, elle ne serait pas mise à jour en même temps ?

Ou un deuxième exemple : disons qu'un yarn.lock est très obsolète et que l'utilisateur exécute yarn add pour ajouter une nouvelle dépendance à package.json. Tous les autres packages obsolètes seront-ils désormais mis à jour dans yarn.lock , ou resteront-ils les mêmes ?

@rarkins

Voulez-vous dire - dans votre exemple ci-dessus - que seuls lodash et ses propres dépendances verront leurs versions de verrouillage mises à jour dans fil.lock ?

Oui. Cela semble être confirmé dans mon exemple.

Tous les autres packages obsolètes seront-ils désormais mis à jour dans fil.lock, ou resteront-ils les mêmes ?

Il semblerait que les lodash arbres de dépendances/entrées de verrous non lodash le seraient.

De mon point de vue, chacun de ces éléments est à la fois souhaitable et attendu.

Préface : J'aime la laine. Mais cela me frustre sans fin.

Dans mon entreprise, yarn install modifie constamment le fichier de verrouillage sur différentes machines (chacune exécutant la même version), bien qu'elle ne modifie jamais package.json . Et quand nous le faisons, nous mettons à jour en utilisant yarn add . C'est ennuyeux car CI vérifie que l'état de git est propre après une construction pour être sûr que nous n'avons pas oublié de faire des choses comme archiver un fichier de verrouillage, et cela change fréquemment.

Mon attente du fil était qu'il assurerait des node_modules identiques sur toutes les machines _par défaut_. Pas avec des drapeaux supplémentaires. Cela donnerait la priorité à l'exactitude plutôt qu'à la commodité. Si je voulais de l'incertitude, je pourrais utiliser npm directement. Lorsqu'un fichier change, c'est pour moi un signal que quelque chose l'a changé et je dois le scruter. Cela ne devrait pas changer.

Des questions

• Est-il dit que malgré la modification du fichier de verrouillage, le contenu de node_modules sera toujours identique à celui de sa génération ? Je ne crois pas que ce soit le cas, mais si c'est le cas, alors je comprends la confusion dans ce fil - cela signifierait que le fil fait la bonne chose malgré l'apparence que ce n'est pas le cas.
• Lorsque package.json change, le fichier de verrouillage est régénéré. Cela ne pourrait-il pas involontairement changer beaucoup de dépendances en fonction de l'état des node_modules de ce programmeur particulier? Le fil doit déterminer un delta et essayer de préserver au mieux les verrous existants (s'il ne le fait pas déjà).
• Pourquoi yarn add spécifie les versions dans package.json avec un ^ ? Encore une fois, j'ai compris que la promesse de fil était de geler les dépendances.

Bogues liés

• Lorsqu'un paquet aléatoire est supprimé dans node_modules , yarn install indique le succès sans le réinstaller. Quand beaucoup d'entre eux sont partis, il les réinstalle. npm est un peu plus approfondi à cet égard.
• Le fichier de verrouillage a tendance à être régénéré si vous supprimez node_modules et effectuez une installation propre (ce qui est littéralement le contraire de ce à quoi vous vous attendriez - je m'attends à ce qu'il installe exactement ce qu'il y a dans le fichier de verrouillage et ne fasse absolument rien d'autre)
• Si vous supprimez le fichier de verrouillage sans toucher au package ou node_modules après une installation propre, le fil le régénère et est généralement très différent de la version précédente. C'est comme un compilateur produisant un code différent à chaque fois que vous l'exécutez sans rien changer.

Dans l'ensemble, fil accélère les installations, mais semble échouer dans sa (in)compétence principale : geler les versions, de manière cohérente, par défaut. Je n'ai pas besoin de commodités qui m'aident à démarrer mon projet, j'ai besoin d'aide pour le maintenir au sein d'une énorme équipe pendant de nombreuses années. Les programmeurs sont intelligents et intentionnels, quand ils veulent un changement, ils le demandent explicitement.

Le fichier de verrouillage en constante évolution n'inspire pas confiance et est un problème constant. Je préférerais des avertissements et des erreurs indiquant que package.json ne correspond pas au fichier de verrouillage, que le fichier de verrouillage ne correspond pas à node_modules, qu'une version verrouillée n'existe plus, etc. prendre des décisions intentionnelles concernant mes dépendances.

@jspiro , merci d'avoir écrit ceci.
Il y a quelques problèmes soulevés ici.
Il vaudrait mieux ouvrir chaque numéro séparément sinon ils seront perdus dans les commentaires.

Êtes-vous sur la dernière version de Yarn?
À partir de 0.18-0.19, nous ne voyons pas de modifications des fichiers fils.lock entre les machines.

Des questions:

Est-il dit que malgré la modification du fichier de verrouillage, le contenu de node_modules sera toujours identique à celui de sa génération ? Je ne crois pas que ce soit le cas, mais si c'est le cas, alors je comprends la confusion dans ce fil - cela signifierait que le fil fait la bonne chose malgré l'apparence que ce n'est pas le cas.

Les dépendances de développement et facultatives peuvent être omises pour le même fichier de verrouillage.
Mais ceux qui sont installés par bing, à l'exception des packages spécifiques à la plate-forme, node_modules doit avoir des packages identiques à des endroits identiques.

Lorsque package.json change, le fichier de verrouillage est régénéré. Cela ne pourrait-il pas involontairement changer beaucoup de dépendances en fonction de l'état des node_modules de ce programmeur particulier? Le fil doit déterminer un delta et essayer de préserver au mieux les verrous existants (s'il ne le fait pas déjà).

C'est une belle demande de fonctionnalité, j'adorerais voir un PR pour cela.

Pourquoi le fil ajoute-t-il des versions spécifiées dans package.json avec un ^ ? Encore une fois, j'ai compris que la promesse de fil était de geler les dépendances.

Cela reflète le comportement de npm.
Vous pouvez faire yarn add [email protected] ou yarn add is-array --exact pour la version exacte.
Peut-être qu'à un moment donné, nous devrions faire des versions exactes par défaut, cela peut être une discussion dans un RFC.

Lorsqu'un package aléatoire est supprimé dans node_modules, l'installation de fil indique le succès sans le réinstaller. Quand beaucoup d'entre eux sont partis, il les réinstalle. npm est un peu plus approfondi à cet égard.

Le fil exécute une vérification rapide et superficielle par défaut.
Faire une vérification plus approfondie sera plus lent, mais nous y travaillons, j'ai une idée de la façon dont nous pourrions faire une vérification rapide et approfondie.
Cependant, vous n'êtes pas censé toucher aux fichiers dans node_modules, la vérification de chaque fichier pour modification entraînerait une expérience d'installation très lente.
Si vous souhaitez ignorer la vérification superficielle, supprimez le fichier node_modules/.yarn-integrity avant l'installation. Ceci n'est pas officiel et peut changer.
Un moyen officiel consiste à exécuter yarn install --force , cela forcerait l'installation complète mais cela réécrirait wire.lock comme effet secondaire.

Le fichier de verrouillage a tendance à être régénéré si vous supprimez node_modules et effectuez une installation propre (ce qui est littéralement le contraire de ce à quoi vous vous attendriez - je m'attends à ce qu'il installe exactement ce qu'il y a dans le fichier de verrouillage et ne fasse absolument rien d'autre)

Je n'ai pas vu ça depuis un moment.
Ouvrez un problème et mettez-moi un cc si cela peut être reproduit.

Si vous supprimez le fichier de verrouillage sans toucher au package ou aux node_modules après une installation propre, fil le régénère et est généralement très différent de la version précédente. C'est comme un compilateur produisant un code différent à chaque fois que vous l'exécutez sans rien changer.

Après un certain temps, de nouvelles versions des dépendances transitives peuvent avoir été publiées.
À cause de cela, la structure de node_modules peut changer de manière significative en raison de la logique de levage.
Cela fonctionne comme prévu.
Il y a une commande import venir https://github.com/yarnpkg/yarn/pull/2580.
Cela vous permettrait de générer un fichier de verrouillage à partir de node_modules existants.

@jspiro , Yarn est un jeune projet communautaire, vos

Une chance d'obtenir au moins une option pour définir le comportement par défaut souhaité ?

Actuellement, nous résolvons ce problème https://github.com/yarnpkg/yarn/issues/3490 , parfois yarn install peut entraîner l'optimisation du fichier de verrouillage, ce qui n'est pas un comportement attendu et nous le corrigerons.
C'est peut-être la raison pour laquelle vous demandez cette modification, sinon le fichier fil.lock ne devrait changer que si vous modifiez manuellement package.json.

Vous pouvez définir --pure-lockfile/--frozen-lockfile sur true dans .yarnrc et il sera ajouté à la commande d'installation par défaut :

--install.pure-lockfile true

Mon problème est que si je n'utilise pas pure-lockfile, j'obtiens la mauvaise version des dépendances installées. Ce n'est pas lié aux changements indésirables de fil.lock

Pouvez-vous soumettre un problème avec les étapes de repro ?
On va arranger ça

J'ai également été mordu par cela lorsqu'un package.json et un yarn.lock se sont désynchronisés en raison d'un développeur ajoutant par erreur une dépendance via npm install --save au lieu de yarn add .

Je ne suis pas d'accord cependant que pure-lockfile devrait être la valeur par défaut et je soutiens que plutôt frozen-lockfile devrait être la valeur par défaut pour yarn install .

Comme frozen-lockfile génère un message d'erreur si yarn.lock et package.json sont pas synchronisés. Le frozen-lockfile est donc très utile sur une machine de construction (c'est-à-dire jenkins) car il marquera ces constructions, comme il faut s'y attendre, comme un échec.

C'est ensuite au développeur de décider quelle version ajouter dans le package.json / fil.lock.

La valeur par défaut malheureuse de yarn install récupérera simplement la version la plus récente des dépendances non encore verrouillées et écrira une version mise à jour yarn.lock , qui ne fera jamais partie du projet. Par conséquent, permettant de futures interruptions de la construction en raison d'une modification inattendue de la version. C'est la raison même pour laquelle nous avons un fichier de verrouillage pour commencer.

L'essentiel devrait être cependant :

Seules les commandes comme add , remove et upgrade devraient muter le yarn.lock .

install devrait juste le faire, à savoir soit installer les dépendances dans leur version verrouillée, soit échouer s'il détecte une incompatibilité entre le package.json et le yarn.lock . (La seule exception étant s'il n'y a pas de yarn.lock en premier lieu. Ensuite, et alors seulement, il peut en créer un, mais il ne devrait plus jamais le toucher.)

Le fichier de verrouillage gelé est donc très utile sur la machine de construction (c'est-à-dire jenkins) car ces constructions échoueront.

Je pense que nous pouvons activer cela automatiquement lorsque nous détectons que nous sommes en mode CI ?

@BYK Je n'avais pas réalisé que ce problème était fermé avant de l'ajouter ici. Dois-je peut-être en ouvrir un nouveau ou celui-ci peut-il être rouvert?

Je dirais en ouvrir un nouveau ☺️

Je suis d'accord avec @thejameskyle et @kittens que fil.lock doit être synchronisé automatiquement avec package.json

Je ne sais pas si cela a été dit, mais juste au cas où : vous n'avez pas besoin d'invalider le fil.lock entier lorsque quelque chose dans package.json change. Vous pouvez invalider uniquement les dépendances des packages qui ont été modifiés à l'intérieur de package.json. Par exemple, si vous n'avez mis à jour que TypeScript, les dépendances de TypeScript devraient être modifiées (en tenant compte des autres packages inchangés).