Je ne pense pas que ce soit un bug. J'ai pu reproduire le problème mais la différence était

52,55d51
< ansi-regex@*:
<   version "3.0.0"
<   resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-3.0.0.tgz#ed0317c322064f79466c02966bddb605ab37d998"
<
1352c1348
< imurmurhash@*, imurmurhash@^0.1.4:
---
> imurmurhash@^0.1.4:

Ce changement n'est qu'une optimisation du fichier de verrouillage et ne change pas la sémantique. Nous prévoyons d'ajouter un avertissement lorsque le fichier de verrouillage a besoin d'une mise à jour lors de l'exécution de yarn install mais si vous voulez vous assurer que votre fichier de verrouillage reste le même et est précis, vous devez utiliser l'option --frozen-lockfile .

Je dois admettre que ce n'est pas intuitif et que nous essayons de trouver une bonne solution à ce problème. Vous pouvez suivre ou contribuer à la discussion sur # 4147.

Si vous acceptez que ce n'est pas un bug et que # 4147 est un bon endroit pour continuer la discussion, veuillez fermer le problème :)

@BYK merci pour votre réponse réfléchie. Après avoir lu # 4147, je suis sur le point de fermer ce problème. J'espère qu'un peu plus de discussion ici pourra vous aider.

4147 semble concerner exclusivement le cas où yarn.lock et package.json ne sont pas synchronisés - en fait, la seule optimisation du temps est mentionnée dans ce commentaire: https://github.com/yarnpkg/yarn/issues/4147 #issuecomment -321894341 - et ce commentaire touche au problème qui me préoccupe: yarn modifiant le fichier yarn.lock alors qu'aucune modification n'a été apportée à package.json .

Il me semble que le fichier yarn.lock ne devrait changer que si mes dépendances changent d'une manière ou d'une autre. En fait, jusqu'à présent, j'ai dit à mes développeurs que s'ils voyaient un changement dans le fichier yarn.lock , il était temps d'exécuter yarn install . Avec les mises à jour récentes, plusieurs ont rapporté qu'après avoir reçu mes modifications et exécuté yarn install , leur fichier de verrouillage a changé (l'optimisation). Cela crée une situation déroutante - devraient-ils engager le changement? Dois-je en quelque sorte pré-optimiser le fichier de verrouillage (est-ce même possible)?

Il semble que je doive, à court terme, ajouter --frozen-lockfile true à .yarnrc dans tous mes dépôts - mais je ne suis pas un grand fan de cette solution car elle exclut le flux de travail mentionné dans # 4147 où vous éditez le package.json puis exécutez yarn install .

Est-ce que toute invocation de yarn pourrait modifier yarn.lock ?

@BYK Je suis désolé de vous déranger à ce sujet car je sais que vous êtes très occupé - mais j'espère obtenir une réponse définitive à ce sujet. Mon flux de travail pour distribuer les changements de dépendance à mon équipe s'est transformé en ceci:

yarn add [blah]
rm -r node_modules yarn.lock
yarn install
rm -r node_modules
yarn install

Cela semble mettre à jour correctement le fichier de verrouillage (voir # 4476), puis optimiser le fichier de verrouillage afin que mes coéquipiers ne vérifient pas les modifications du fichier de verrouillage.

Mon équipe utilise-t-elle du fil de manière incorrecte? Devrions-nous nous attendre à ce que le fichier de verrouillage change avec chaque commande install ?

@artlogic À mon humble avis , vos coéquipiers devraient être autorisés à enregistrer les modifications du fichier de verrouillage, même s'il ne s'agit que d'optimisations. Je suis d'accord avec l'idée que yarn install optimisation du fichier de verrouillage est contre-intuitive, mais toujours quelque chose que chaque développeur de votre équipe pourrait commettre en toute sécurité. Je ne comprends pas pourquoi vous voulez interdire cela.

Cela étant dit, votre flux de travail peut entraîner des effets secondaires inattendus, car vous abandonnez pratiquement les versions verrouillées. La suppression du fichier de verrouillage signifie que yarn doit à nouveau résoudre toutes les versions de dépendances, et il essaiera de récupérer la version la plus récente comme indiqué dans votre package.json ce qui entraînera une rupture potentielle, esp. si plusieurs dépendances se cassent en même temps dans une version future.

Si vous souhaitez toujours faire en sorte que l'installation ne touche pas lockfile, vous devez utiliser l'indicateur frozen-lockfile :

 yarn add {blah}

Archivez lockfile, puis un autre dev utiliserait:

   yarn install --frozen-lockfile

NE PAS AJOUTER --frozen-lockfile à true en .yarnrc car cela vous empêche de mettre à jour, voir: # 4570

Si vous souhaitez mettre à niveau vos dépendances, exécutez:

 yarn upgrade

Si vous souhaitez mettre à niveau une seule dépendance:

  yarn upgrade {blah}

Vous pouvez également simplement installer une version spécifique d'une dépendance:

  yarn install {blah}@1.5

Cela permet des réglages plus fins et moins de maux de tête à long terme.

@ k0pernikus - merci pour votre réponse détaillée. Tout d'abord, je dois m'excuser d'avoir confondu deux problèmes - # 4476 est le moteur d'une partie de mon flux de travail. Le fait que yarn upgrade semble quelque peu cassé n'a rien à voir avec ce problème, bien sûr.

En ce qui concerne le flux de travail, je ne peux pas imaginer que la mienne soit la seule équipe où un développeur est chargé de maintenir / tester les nouvelles dépendances tandis que les autres développeurs travaillent sur la base de code. Le gros problème que j'ai avec ce qui a commencé est que je voudrais installer / tester de nouvelles dépendances, dire à tout le monde d'exécuter yarn install et ensuite obtenir 4-5 questions pour savoir si le yarn.lock modifié doit être validé . Il semble que je serais dans un pire endroit si je disais "si le fichier de verrouillage change, validez-le" parce qu'à ce stade, je pourrais me retrouver avec un verrou de validation qui ressemble à ceci:

• yarn.lock changé (dev4)
• yarn.lock a changé (dev3)
• yarn.lock a changé (dev2)
• yarn.lock a changé (dev1)
• Dépendances mises à jour (moi)

Cependant, il se peut que ce soit juste la façon dont yarn est censé fonctionner, donc pour les projets de mon équipe, nous changerons tous nos dépôts pour utiliser un fichier de verrouillage gelé de sorte que seuls add et upgrade causent le lockfile à modifier.

Un scénario supplémentaire ... il semble que cela pourrait être un ennui potentiel pour les projets avec beaucoup de contributeurs car potentiellement chaque fois qu'ils clonent et installent, le fichier de verrouillage peut changer. Je ne voudrais certainement pas ces optimisations dans les pull requests. L'intention est-elle que la plupart des projets FOSS utilisent également une transition de fil vers un fichier de verrouillage gelé?

@artlogic Notre équipe a --install.pure-lockfile true dans le .yarnrc du projet exactement pour cette raison.

@jboler - Je n'avais jamais vu ce paramètre auparavant. Je vais devoir jeter un coup d'œil, mais il semble que je suggère que nous ajoutions cela au .yarnrc pour tous nos dépôts, et tous les dépôts de tous les projets FOSS que j'ai.

Si quelqu'un de l'équipe de fil peut confirmer que l'intention est que yarn install peut et changera le fichier de verrouillage à chaque exécution (malgré aucune modification des dépendances), je fermerai ce problème.

@artlogic désolé pour la réponse tardive.

Le fait est qu'il est __attendu__ que yarn install change potentiellement le fichier de verrouillage. Je sais que ce n'est pas idéal et nécessite une meilleure communication. Je veux vraiment avoir un meilleur défaut, mais en attendant, je pense que quelque chose comme @jboler suggéré avec, mais peut-être utiliser --frozen-lockfile place, serait la meilleure solution jusqu'à ce que nous déterminions comment le fil devrait se comporter dans différents scénarios comme pour workflows où les gens préfèrent simplement modifier package.json pour mettre à jour les dépendances au lieu d'utiliser yarn add etc.

@BYK Je suis d'accord avec @artlogic . Ce comportement est très déroutant:

Le gros problème que j'ai avec ce qui a commencé est que je voudrais installer / tester de nouvelles dépendances, dire à tout le monde d'exécuter yarn install et ensuite obtenir 4-5 questions pour savoir si le yarn.lock modifié doit être validé.

Notre équipe est composée d'environ 50 personnes qui gèrent yarn install chaque jour :(

@vkrol vous devriez être en mesure d'archiver un fichier .yarnrc qui a --install.frozen-lockfile true ou --install.pure-lockfile true pour éviter les problèmes jusqu'à ce que Yarn change son comportement. Cela aiderait-il?

@BYK pure-lockfile nous aidera, mais pas frozen-lockfile . Si je comprends bien, yarn install échouera avec une erreur si le fichier de verrouillage gelé est activé. Ce comportement est absolument inacceptable dans notre cas.

@vkrol ma préférence est frozen-lockfile car il échouera uniquement si votre fichier de verrouillage doit être modifié et n'est pas cohérent. Avec pure-lockfile vous pouvez avoir un fichier de verrouillage presque inutile ou très inexact, mais vous n'obtiendrez toujours pas un échec. Yarn utiliserait simplement les résolutions internes qu'il calculait avec bonheur. Si tous les membres de votre équipe utilisent exactement la même version de Yarn, cela devrait être bien. Sinon, cela peut être dangereux.

@BYK peut-être que je ne comprends pas correctement le comportement de frozen-lockfile . Échoue-t-il lorsque le fichier de verrouillage est cohérent avec le contenu package.json, mais qu'une optimisation interne est nécessaire?

@vkrol cela ne devrait pas échouer lorsque le fichier peut être optimisé davantage, mais il est cohérent avec package.json et est cohérent en lui-même. Sinon, c'est un bug. Il existe même un test pour cela: https://github.com/yarnpkg/yarn/blob/0415b07b3293ab125a77f3f66fe14034d6e5b376/__tests__/commands/install/lockfiles.js#L72 -L84

@BYK je n'en savais rien. Je vais essayer cette option, merci! Je pense que ce fait devrait être documenté quelque part.

@BYK

il ne devrait pas échouer lorsque le fichier peut être optimisé davantage, mais il est cohérent avec package.json et est cohérent en soi.

J'ai trouvé un inconvénient à l'utilisation de ce drapeau. Si yarn.lock peut être optimisé alors les invocations répétées de cette commande yarn install --frozen-lockfile ne sont pas optimisées via le contrôle "d'intégrité" comme sans cet indicateur. C'est un bug? Dois-je créer le problème distinct?

@BYK Merci pour votre réponse. Pour les projets de mon équipe, nous utilisons maintenant frozen-lockfile et les choses fonctionnent (relativement) bien. Cette question reste cependant assez préoccupante pour moi. Plus précisément, les optimisations inutiles que Yarn apporte au fichier de verrouillage lors de l'exécution de yarn install .

Voici l'exemple le plus clair que je puisse donner de l'endroit où ce comportement pose des problèmes:

1. J'ajoute une nouvelle dépendance en utilisant yarn add [blah] et je valide mes package.json et yarn.lock .
2. Les contributeurs à mon package déroulent les modifications et remarquent que yarn.lock a été mis à jour, et exécutent donc un yarn install .
3. Dans certains cas, ces contributeurs se retrouvent avec un yarn.lock modifié après l'installation. Que doivent-ils faire dans ce cas? Est-ce une course pour voir qui peut soumettre la demande d'extraction en premier?

Pour être clair, je n'ai aucun problème avec yarn install modifiant yarn.lock si package.json a été modifié. Mon problème est l'optimisation lorsque package.json n'a pas été modifié. Je vois trois solutions possibles:

1. Dirigez tout projet qui gère les dépendances de manière centralisée pour ajouter --install.frozen-lockfile true à un fichier .yarnrc . Ce serait probablement BEAUCOUP de projets - la plupart des packages NPM je suppose.
2. Fournissez un commutateur pour forcer Yarn à optimiser le fichier de verrouillage pendant la phase d'ajout, par exemple yarn add --optimize [blah] . Ensuite, demandez aux responsables du package de toujours utiliser ce commutateur.
3. Interdire à yarn d'optimiser yarn.lock pendant la phase d'installation à moins que package.json semble avoir été mis à jour.

Je préconise l'option 3, mais je pourrais voir l'option 2 être également un choix raisonnable.

Merci pour votre temps!

J'aime un peu l'idée que yarn install ne met pas à jour le fichier yarn.lock mais émet à la place un avertissement disant que "Votre fichier yarn.lock est obsolète, exécutez yarn blah pour mettez-le à jour maintenant ».

@BYK pourquoi ~ n'applique-t-il pas ~ des optimisations à yarn.lock sur yarn install plutôt que lorsque add / upgrade sont exécutés?

modifier: corriger une faute de frappe

@ spencer-brown: d'après ce que j'ai vu, il applique en fait des optimisations à l'installation - c'est ce que je trouve problématique

L'optimisation de yarn.lock ne devrait-elle pas être exécutée sur yarn add? yarn.lock changera de toute façon. C'est l'option numéro deux dans le commentaire récent de @artlogic , non? Pourquoi l'optimisation n'a-t-elle pas lieu alors, pour que personne d'autre ne doive valider un autre changement yarn.lock?

@artlogic oups, faute de frappe :) - mon commentaire devrait dire "fait"; édité.

Nous utilisons beaucoup composer et composer install ne touche jamais le fichier de verrouillage.

composer update ou composer require (équivalent à yarn add ) doit être exécuté pour toute modification ou optimisation à apporter au fichier de verrouillage.

Depuis de nombreuses années, nous n'avons jamais eu à nous soucier du comportement ambigu de composer install .

Je me rends compte que le fil remplit un rôle légèrement différent, mais le compositeur a le problème équivalent des mises à jour manuelles apportées à composer.json et il se désynchronise avec le fichier de verrouillage. Actuellement, composer install ignorera complètement le fichier composer.json et émettra un avertissement.

Nous utilisons beaucoup composer et composer install ne touche jamais le fichier de verrouillage.

composer update ou composer require (équivalent à yarn add ) doit être exécuté pour toute modification ou optimisation à apporter au fichier de verrouillage.

Depuis de nombreuses années, nous n'avons jamais eu à nous soucier du comportement ambigu de composer install .

Je me rends compte que le fil remplit un rôle légèrement différent, mais le compositeur a le problème équivalent des mises à jour manuelles apportées à composer.json et il se désynchronise avec le fichier de verrouillage. Actuellement, composer install ignorera complètement le fichier composer.json et émettra un avertissement.

hé les enfants, le fichier de verrouillage ne devrait jamais changer lors des installations suivantes. c'est juste stupide. si vous pensez que l'optimisation vaut la peine d'y toucher, créez simplement un fichier séparé à la place qui n'entre pas dans le contrôle de version.

Comme avec Gemfile.lock de Bundler, l'intérêt de yarn.lock est que chaque fois que l'installation de yarn est exécutée, vous pouvez garantir des résultats déterministes dans tous les environnements. Si l'installation de fil modifie le fichier de verrouillage, vous perdez cette garantie. D'autres commandes telles que yarn add ou yarn update devraient évidemment changer yarn.lock mais pas yarn install. Notre équipe a rencontré des problèmes où nous avons des versions de package légèrement différentes installées dans différents environnements, ce que nous ne voulons pas.

J'ai tendance à penser que yarn install --pure-lockfile devrait être la valeur par défaut, et il pourrait y avoir une option --fix-my-dev-process-inconsistencies-for-me-magically pour obtenir le comportement actuel.

@ryancastle --pure-lockfile ne vous dira pas qu'une mise à jour est pour votre fichier de verrouillage. Cela n'en génère pas un. Cela peut encore conduire à un comportement inattendu. --frozen-lockfile échouera si une mise à jour est requise.

J'opère avec --install.frozen-lockfile true dans mon .yarnrc depuis un certain temps maintenant et cela semble fonctionner d'une manière saine. L'astuce consiste à créer le yarn.lock initial pour le dépôt sans cet indicateur en vigueur. Une fois créées, les installations ne peuvent pas modifier le yarn.lock , mais les mises à jour le peuvent. Une fois que j'ai commencé à utiliser ce flux de travail, le nombre de modifications accidentelles de yarn.lock tombé à zéro.

@artlogic Sidenote: J'avais l'habitude d'avoir frozen-lockfile true dans mon .yarnrc aussi, maintenant je ne l'applique que sur le serveur de construction, car nous avons rencontré des problèmes étaient des changements intentionnels au yarn.lock n'ont pas été créés, par exemple en essayant de synchroniser un package.json modifié avec le yarn.lock , car un développeur a modifié manuellement le package.json ou a utilisé npm pour ajouter des dépendances.

Voir: https://github.com/yarnpkg/yarn/issues/4570

Le cas d'utilisation de @ k0pernikus est la raison pour laquelle nous n'avons pas fait de --frozen-lockfile la valeur par défaut avec yarn install . Honnêtement, je ne sais pas ce que serait un bon compromis sans gêner les gens qui éditent package.json puis exécutent yarn install pour mettre à jour le fichier de verrouillage. J'ai proposé un drapeau ou une nouvelle commande comme yarn sync mais l'idée doit être étoffée puis jugée par la communauté avant d'être mise en œuvre.

De plus, ce serait un changement radical, il faudrait donc Yarn 2.x :)

un drapeau ou une nouvelle commande comme la synchronisation du fil

me semble bon 👍. et yarn install pourrait afficher un avis "package.json et yarn.lock ne sont pas synchronisés. Exécutez 'yarn sync' pour mettre à jour le fichier de verrouillage"

Honnêtement, je ne sais pas ce que serait un bon compromis sans gêner les gens qui éditent package.json, puis exécutent yarn install pour mettre à jour le fichier de verrouillage.

Je pense qu'à un certain moment, une décision doit être prise pour déterminer quel est le flux de travail approprié. Pour moi, activer cela semble presque encourager un anti-modèle.

J'ai proposé un drapeau ou une nouvelle commande comme yarn sync mais l'idée doit être étoffée puis jugée par la communauté avant d'être mise en œuvre.

Cela me semble être un compromis raisonnable. Si vous insistez pour éditer manuellement votre package.json , il est logique d'exécuter une commande pour synchroniser les choses.

Voici ce que j'aimerais voir:

• yarn install sans yarn.lock crée le yarn.lock .
• yarn install avec un yarn.lock ne le modifie pas. S'il trouve qu'il y a un écart entre yarn.lock et package.json une erreur est renvoyée (comme @indeyets indiqué).
• yarn sync (ou peut-être yarn install -s ) obtient yarn.lock nouveau synchronisé avec package.json .

J'ai toujours une préoccupation sous-jacente que yarn install modifie le yarn.lock même si package.json n'est pas désynchronisé avec le fichier de verrouillage. Vous verrez ci-dessus qu'il effectue quelques "optimisations". Serait-il possible à tout le moins de désactiver ce comportement sans changement radical?

J'ai toujours une préoccupation sous-jacente que l'installation de yarn modifie le yarn.lock même lorsque package.json n'est pas désynchronisé avec le fichier de verrouillage. Vous verrez ci-dessus qu'il effectue quelques "optimisations". Serait-il possible à tout le moins de désactiver ce comportement sans changement radical?

Même sentiment ici. Je pensais que c'était la raison spécifique pour laquelle cette question restait ouverte. Comme la "synchronisation" est discutée dans # 4147

C'est pourquoi j'ai recherché ce problème en premier lieu.

Allons-nous fusionner ceci et # 4147?

@BYK Je pense que presque tout ce qui a été discuté ici peut être fusionné avec # 4147. Comme je l'ai déjà dit, je pense que la seule chose qui me préoccupe encore, ce sont les "optimisations" que yarn install effectue sur yarn.lock même si aucun changement n'a été apporté à package.json .

Ma pensée est qu'en tant que solution provisoire sur la voie du fil 2.0, ces optimisations devraient être désactivées. Je ne pense pas que ce serait un changement radical.

Je suis à 100% d'accord avec @artlogic .

J'étais en train de configurer CircleCI et ma build échouait et je l'ai retracé jusqu'à un problème de mise en cache avec yarn.lock . Venant de Rails, je m'attendrais à ce que le fichier de verrouillage soit verrouillé par une commande d'installation.

Voici ce qui est suggéré pour la vérification du cache sur CircleCI: https://circleci.com/docs/2.0/yarn/

#...
      - restore_cache:
          name: Restore Yarn Package Cache
          keys:
            - yarn-packages-{{ checksum "yarn.lock" }}
      - run:
          name: Install Dependencies
          command: yarn install
      - save_cache:
          name: Save Yarn Package Cache
          key: yarn-packages-{{ checksum "yarn.lock" }}
          paths:
            - ~/.cache/yarn
#...

Cela ne fonctionnera jamais car yarn.lock peut changer, alors qu'il ne le devrait pas.

Pour info, sur le fil 1.10.1 sous macOS 10.13.6, j'ai juste essayé le stimulus de bogue de l'OP, et j'ai trouvé que yarn.lock n'avait pas changé. En d'autres termes, quand j'ai essayé:

yarn init
yarn add cordova
cp yarn.lock yarn.lock.initial
rm -r node_modules
yarn install
diff yarn.lock.initial yarn.lock

Ainsi, lors de l'utilisation de yarn 1.10.1, le yarn install n'a pas changé yarn.lock , comme il l'avait fait pour l'OP lors de l'utilisation de yarn 1.0.1. (Je considère que c'est une bonne chose, comme je pense que l'OP.)

@dtgriscom C'est génial que le problème ne se produise plus pour Cordova! Je me demande si cela a été entièrement corrigé ou si le fil pourrait encore tenter d'optimiser le fichier de verrouillage lors de l'installation?

Ce serait bien de le savoir, non? Vous avez noté que le problème était spécifique au package; il est logique que cela soit également spécifique à la version. (Je n'ai jamais entendu de justification pour "nous voulons changer quelque chose qui ne devrait pas changer"; autre que "nous optimisons" ...)

Je suis tout à fait d'accord qu'une opération install doit être déterministe par défaut. La mise à jour d'un fichier .lock devrait obliger le développeur à effectuer une action dont il sait qu'elle produira une modification dans le fichier. Par exemple, vous pouvez exécuter quelque chose comme yarn install --optimize qui permettrait une petite optimisation qui ne rompt pas l'état actuel des packages.

Ajouter des options séparées que je dois rechercher dans la documentation juste pour avoir la certitude que mon fichier de verrouillage n'est pas touché sans ma permission est assez déroutant, surtout si elles peuvent provoquer un échec. En tant que développeur, je m'attends à avoir le contrôle sur les outils que j'utilise et j'ai l'impression que ce comportement m'enlève cela.

Veuillez reconsidérer le basculement du comportement par défaut pour ne pas modifier le fichier de verrouillage et opérer uniquement sur celui-ci lors de l'installation des dépendances. Une vérification d'intégrité avec un avertissement que package.json n'est pas synchronisé avec le fichier de verrouillage est vraiment tout ce dont les gens ont besoin.

J'ai dit aux gens que les PR incluant les modifications du fichier de verrouillage ne seront pas fusionnés car le fichier de verrouillage n'est modifié que lors de l'ajout de nouvelles dépendances ou de la mise à jour de dépendances. Voici ce que dit la documentation d'installation :

yarn install

Installez toutes les dépendances répertoriées dans package.json dans le dossier local node_modules .

Le fichier yarn.lock est utilisé comme suit:

• Si yarn.lock est présent et suffit à satisfaire toutes les dépendances répertoriées dans package.json , les versions exactes enregistrées dans yarn.lock sont installées et yarn.lock seront inchangées . Yarn ne vérifiera pas les versions plus récentes.
• Si yarn.lock est absent, ou n'est pas suffisant pour satisfaire toutes les dépendances répertoriées dans package.json (par exemple, si vous ajoutez manuellement une dépendance à package.json ), Yarn recherche le dernières versions disponibles qui satisfont les contraintes de package.json . Les résultats sont écrits dans yarn.lock .

Si vous voulez vous assurer que yarn.lock n'est pas mis à jour, utilisez --frozen-lockfile .

La documentation est-elle erronée car il y a ces optimisations qui peuvent se produire énoncées ci-dessus ou est-ce un bogue à prendre en compte pour le moment?

ps. cela arrive toujours, et yarn --frozen-lockfile n'échoue pas quand il le fait.

J'utilise actuellement --frozen-lockfile dans mon fichier .yarnrc , ce qui empêche efficacement yarn de modifier le fichier yarn.lock lors de l'exécution de yarn install sur différentes machines. Mais cela empêche également yarn add blahblah de modifier mon yarn.lock. Est-ce le comportement correct ou je manque quelque chose? J'ai lu tout le fil de discussion et il me semble que --frozen-lockfile est l'approche recommandée pour le moment?

@konekoya Oui, vous avez raison de

yarn install --frozen-lockfile

et ne peut pas se fier au paramètre de .yarnrc car cela empêchera votre yarn.lock de se mettre à jour.

Selon le contenu de vos .npmrc et .yarnrc vous pourrez peut-être utiliser

yarn install --no-default-rc {dependency}

mais je ne me fierais pas à cela (car cela se briserait dès que vous auriez d'autres paramètres dans vos fichiers rc.)

Voir mon commentaire et le numéro pertinent: # 4570, esp. ma conclusion .

Merci d'avoir clarifié cela @ k0pernikus. Vous venez de faire ma journée :)

@BYK pourquoi yarn applique-t-il des optimisations à yarn.lock sur yarn install plutôt que lorsque add / upgrade sont exécutés?

Je pense que le commentaire de @ spencer-brown est essentiel pour "résoudre" ce problème. Je viens de tester pour moi-même et en cours d'exécution yarn upgrade et ensuite yarn On m'a dit "Déjà à jour.". J'ai donc supprimé mon node_modules et j'ai lancé yarn ce qui a abouti au fichier de verrouillage "optimisé" que les autres développeurs de mon projet auraient fini si j'avais poussé celui que j'ai obtenu de yarn upgrade .

Maintenant, si yarn upgrade (et yarn add ) exécutait la même optimisation que yarn install nous n'aurions pas ce problème en premier lieu. On a beaucoup parlé de ne pas vouloir casser une fonctionnalité existante et je ne vois pas l'exécution de l'optimisation après yarn upgrade et yarn add comme casser quoi que ce soit - juste en la rendant un peu plus lente.

Pour contourner le problème, je pense demander à tous nos développeurs de supprimer node_modules chaque fois qu'ils ont besoin de mettre à jour le fichier de verrouillage pour forcer l '"optimisation" avant de pousser les fichiers de verrouillage vers d'autres. Ou peut-être qu'ils peuvent exécuter yarn upgrade && yarn prune - peut-être que cela ferait l'affaire?

Pour contourner le problème, je pense demander à tous nos développeurs de supprimer node_modules chaque fois qu'ils ont besoin de mettre à jour le fichier de verrouillage pour forcer l '"optimisation" avant de pousser les fichiers de verrouillage vers d'autres. Ou peut-être qu'ils peuvent exécuter yarn upgrade && yarn prune - peut-être que cela ferait l'affaire

Mise à jour: Vous ne pouvez pas exécuter prune manuellement, vous obtenez juste ce message: _ "La commande prune n'est pas nécessaire. yarn install élagera les paquets superflus" ._ Et puisque vous ne pouvez pas exécuter l'installation non plus parce que vous sont _ "Déjà à jour" _ Je suppose que nous allons supprimer node_modules puis exécuter yarn pour faire l'élagage.

Pour moi, le plus gros argument de vente pour yarn est le comportement prévisible et fiable du fichier de verrouillage. Changer le fichier de verrouillage sur yarn install me donne une réelle anxiété.

Pour moi, le plus gros argument de vente pour yarn est le comportement prévisible et fiable du fichier de verrouillage. Changer le fichier de verrouillage sur yarn install me donne une réelle anxiété.

Le fichier de verrouillage est présenté comme une spécification exacte de ce qui sera installé, afin que nous n'ayons pas à nous soucier de ce qui sera installé. Utilisez le même fichier de verrouillage et vous obtiendrez la même installation à chaque fois. Mais parfois yarn changera de sa propre initiative, pour ses propres raisons et sans avertissement, le contenu du fichier de verrouillage. Oui, vous pouvez affirmer que "les changements de fichiers ne changent pas ce qui sera installé", mais pourquoi prendre une garantie aussi claire et la brouiller? Pourquoi me faire me demander si je devrais recommencer le fichier de verrouillage modifié? Pourquoi souiller votre principale revendication de gloire?

C'est vraiment incroyable. D'autres l'ont déjà bien dit. Un fichier de verrouillage ne doit pas changer lors de l'installation. Cela a un impact négatif sur les workflows de validation. Chaque développeur de notre équipe sait dans quelles circonstances le fichier de verrouillage est autorisé à changer. Lorsqu'un fichier de verrouillage change sans que les dépendances soient mises à jour, cela provoque une confusion inutile et une vérification supplémentaire. Il s'agit du gestionnaire de packages de base UX qui vient juste d'être interrompu. S'il-vous-plaît, réparez.

Je viens d'être surpris par ce comportement, en passant de Node.js 13 à 14, tous mes fichiers yarn.lock changé en faisant un yarn install et je me demandais pourquoi ...

Je pense que le comportement approprié serait d'émettre un avertissement si _optimisation_ du fichier yarn.lock de quelque manière que ce soit.