Я не думаю, что это ошибка. Мне удалось воспроизвести проблему, но разница была

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:

Это изменение является просто оптимизацией файла блокировки и не меняет семантику. Мы планируем добавить предупреждение, когда файл блокировки нуждается в обновлении при запуске yarn install но если вы хотите, чтобы файл блокировки оставался неизменным и точным, вам следует использовать параметр --frozen-lockfile .

Я должен признать, что это немного неинтуитивно, и мы пытаемся найти хорошее решение для этого. Вы можете следить за обсуждением # 4147 или участвовать в нем.

Если вы согласны с тем, что это не ошибка, и # 4147 - хорошее место для продолжения обсуждения, пожалуйста, закройте проблему :)

@BYK спасибо за ваш вдумчивый ответ. Прочитав # 4147, я сомневаюсь в том, чтобы закрыть этот вопрос. Я надеюсь, что немного больше обсуждения здесь могут помочь.

4147, похоже, относится исключительно к случаю, когда yarn.lock и package.json не синхронизированы - фактически, единственная оптимизация времени упоминается в этом комментарии: https://github.com/yarnpkg/yarn/issues/4147 #issuecomment -321894341 - и этот комментарий затрагивает проблему, которая меня волнует: пряжа модифицирует файл yarn.lock когда в package.json не было внесено никаких изменений.

Мне кажется, что файл yarn.lock должен меняться только в том случае, если мои зависимости как-то меняются. Фактически, до этого момента я говорил своим разработчикам, что если они видят изменение в файле yarn.lock , пора запускать yarn install . После недавних обновлений некоторые сообщили, что после того, как они получили мои изменения и запустили yarn install , их файл блокировки изменился (оптимизация). Это создает запутанную ситуацию - следует ли им фиксировать изменение? Должен ли я как-то предварительно оптимизировать файл блокировки (возможно ли это)?

Похоже, мне, возможно, придется в краткосрочной перспективе добавить --frozen-lockfile true к .yarnrc во всех моих репозиториях, но я не большой поклонник этого решения, потому что оно исключает рабочий процесс, упомянутый в # 4147, где вы редактируете package.json а затем запускаете yarn install .

Есть ли намерение, что любой вызов пряжи может изменить yarn.lock ?

@BYK Мне очень жаль беспокоить вас по этому поводу, потому что я знаю, что вы очень заняты, но я надеюсь получить исчерпывающий ответ по этому поводу. Мой рабочий процесс по распространению изменений зависимостей среди моей команды превратился в следующее:

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

Похоже, это правильно обновляет файл блокировки (см. # 4476), а затем оптимизирует файл блокировки, чтобы мои товарищи по команде не проверяли изменения файла блокировки.

Моя команда неправильно использует пряжу? Следует ли ожидать, что файл блокировки будет изменяться с каждой командой install ?

@artlogic IMHO, вашим товарищам по команде должно быть разрешено проверять изменения файла блокировки, даже если они просто оптимизации. Я согласен с мнением, что оптимизация файла блокировки yarn install противоречит интуиции, но все же это то, что каждый разработчик вашей команды может безопасно выполнить. Я не понимаю, почему вы хотите это запретить.

При этом ваш рабочий процесс может привести к неожиданным побочным эффектам, поскольку вы в значительной степени отказываетесь от заблокированных версий. Удаление файла блокировки означает, что yarn должен снова разрешить все версии зависимостей, и он попытается получить самую последнюю версию, как указано в вашем package.json приведет к потенциальной поломке, особенно. если в будущей версии одновременно разрывается более одной зависимости.

Если вы все еще хотите, чтобы установка не касалась файла блокировки, вам следует использовать флаг frozen-lockfile :

 yarn add {blah}

Зарегистрируйте файл блокировки, а затем другой разработчик будет использовать:

   yarn install --frozen-lockfile

НЕ ДОБАВЛЯЙТЕ --frozen-lockfile в true в .yarnrc как это мешает вам когда-либо обновляться, см .: # 4570

Если вы хотите обновить свои зависимости, запустите:

 yarn upgrade

Если вы хотите обновить только одну зависимость:

  yarn upgrade {blah}

Вы также можете просто установить определенную версию одной зависимости:

  yarn install {blah}@1.5

Это позволяет более тонкую настройку и меньше головной боли в долгосрочной перспективе.

@ k0pernikus - спасибо за развернутый ответ. Во-первых, я должен извиниться за то, что смешал две проблемы - # 4476 является движущей силой моего рабочего процесса. Тот факт, что yarn upgrade выглядит несколько сломанным, конечно, не имеет ничего общего с этой проблемой.

Что касается рабочего процесса, я не могу себе представить, что моя - единственная команда, в которой один разработчик отвечает за поддержку / тестирование новых зависимостей, в то время как другие разработчики работают над базой кода. Большая проблема, с которой я столкнулся с тем, что началось, заключается в том, что я бы установил / протестировал новые зависимости, сказал всем запустить yarn install а затем получил 4-5 вопросов о том, следует ли зафиксировать измененный yarn.lock . Похоже, что мне было бы хуже, если бы я сказал «если файл блокировки изменится, зафиксируйте его», потому что в этот момент я мог бы получить блокировку фиксации, которая выглядит примерно так:

• yarn.lock изменен (dev4)
• yarn.lock изменен (dev3)
• yarn.lock изменен (dev2)
• yarn.lock изменен (dev1)
• Обновлены зависимости (я)

Однако может оказаться, что yarn работает именно так, поэтому для проектов моей команды мы изменим все наши репозитории на использование замороженного файла блокировки, чтобы только add и upgrade вызывали файл блокировки, который нужно изменить.

Еще один сценарий ... похоже, что это может быть потенциальным раздражителем для проектов с большим количеством участников, потому что потенциально каждый раз, когда они клонируют и устанавливают, файл блокировки может измениться. Я бы определенно не хотел такой оптимизации в запросах на вытягивание. Предполагается ли, что большинство проектов FOSS, использующих пряжу, также перейдут в замороженный файл блокировки?

@artlogic Наша команда имеет --install.pure-lockfile true в .yarnrc проекта именно по этой причине.

@jboler - я раньше не видел такой настройки. Я собираюсь взглянуть, но, похоже, я предлагаю добавить это к .yarnrc для всех наших репозиториев и всех репозиториев любых проектов FOSS, которые у меня есть.

Если кто-то из команды yarn может подтвердить, что намерение состоит в том, что yarn install может и будет изменять файл блокировки при каждом запуске (несмотря на отсутствие изменений в зависимостях), я закрою эту проблему.

@artlogic извините за поздний ответ.

Дело в том, что __expected__ yarn install потенциально может изменить файл блокировки. Я знаю, что это не идеально и требует лучшего общения. Я действительно хочу иметь лучшее значение по умолчанию, но пока я думаю, что что-то вроде @jboler, предложенного, но, возможно, с использованием --frozen-lockfile вместо этого, будет лучшим решением, пока мы не выясним, как пряжа должна вести себя в разных сценариях, например рабочие процессы, в которых люди предпочитают просто редактировать package.json для обновления зависимостей вместо использования yarn add и т. д.

@BYK Я согласился с @artlogic . Такое поведение очень сбивает с толку:

Большая проблема, с которой я столкнулся с тем, что началось, заключается в том, что я бы установил / протестировал новые зависимости, сказал всем запустить yarn install, а затем получил 4-5 вопросов о том, следует ли зафиксировать измененный yarn.lock.

Наша команда состоит из ~ 50 человек, которые ежедневно запускают yarn install :(

@vkrol вы должны иметь возможность проверить файл .yarnrc , содержащий --install.frozen-lockfile true или --install.pure-lockfile true чтобы избежать проблем, пока Yarn не изменит свое поведение. Это поможет?

@BYK pure-lockfile нам поможет, но не frozen-lockfile . Если я правильно понимаю, yarn install выйдет из строя с ошибкой, если замороженный файл блокировки включен. В нашем случае такое поведение абсолютно недопустимо.

@vkrol я предпочитаю frozen-lockfile так как он не сработает, только если ваш файл блокировки нуждается в изменении и не согласован. С pure-lockfile вас может быть файл блокировки, близкий к бесполезному или очень неточному, но вы все равно не получите сбоя. Yarn просто будет использовать внутреннее разрешение, которое она успешно рассчитала. Если все члены вашей команды используют одну и ту же версию Yarn, это должно быть нормально. В противном случае это может быть опасно.

@BYK, возможно, я frozen-lockfile . Сбой, если файл блокировки соответствует содержимому package.json, но требуется некоторая внутренняя оптимизация?

@vkrol он не должен завершиться неудачей, если файл можно оптимизировать дальше, но он согласуется с package.json и сам по себе непротиворечив. Если нет, то это ошибка. Для этого есть даже тест: https://github.com/yarnpkg/yarn/blob/0415b07b3293ab125a77f3f66fe14034d6e5b376/__tests__/commands/install/lockfiles.js#L72 -L84

@BYK Я не знал об этом. Я попробую этот вариант, спасибо! Думаю, что этот факт нужно где-то задокументировать.

@BYK

он не должен завершиться ошибкой, если файл можно оптимизировать в дальнейшем, но он согласуется с package.json и сам по себе непротиворечив.

Я обнаружил обратную сторону использования этого флага. Если yarn.lock может быть оптимизирован, то повторные вызовы этой команды yarn install --frozen-lockfile не оптимизируются с помощью проверки "целостности", как без этого флага. Это ошибка? Нужно ли мне создавать отдельный выпуск?

@BYK Спасибо за ваш ответ. Для проектов моей команды мы теперь используем frozen-lockfile и все работает (относительно) нормально. Однако этот вопрос по-прежнему вызывает у меня беспокойство. В частности, ненужная пряжа оптимизации вносит в файл блокировки при запуске yarn install .

Вот самый ясный пример того, где такое поведение вызывает проблемы:

1. Я добавляю новую зависимость, используя yarn add [blah] и фиксирую свои обновленные package.json и yarn.lock .
2. Авторы моего пакета извлекают изменения и замечают, что yarn.lock был обновлен, и, таким образом, запускают yarn install .
3. В некоторых случаях после установки эти участники получают измененный yarn.lock . Что им делать в этом случае? Это гонка за тем, кто первым сможет отправить пулреквест?

Для ясности: у меня нет проблем с изменением yarn install yarn.lock если package.json было изменено. Моя проблема - оптимизация, когда package.json не было изменено. Я вижу три возможных решения:

1. Направляйте любой проект, который централизованно управляет зависимостями, чтобы добавить --install.frozen-lockfile true в файл .yarnrc . Скорее всего, это будет МНОГО проектов - я думаю, большинство пакетов NPM.
2. Предоставьте переключатель для принудительной оптимизации файла блокировки на этапе добавления, например yarn add --optimize [blah] . Затем дайте указание разработчикам пакетов всегда использовать этот переключатель.
3. Запретить yarn оптимизировать yarn.lock на этапе установки, если только package.json не обновлен.

Я выступаю за вариант 3, но считаю, что вариант 2 также является разумным выбором.

Спасибо за ваше время!

Мне нравится идея, что yarn install не обновляет файл yarn.lock а вместо этого выдает предупреждение о том, что "Ваш файл yarn.lock устарел, запустите yarn blah чтобы обновите его сейчас.

@BYK, почему ~ не ~ применяет ли yarn оптимизацию к yarn.lock на yarn install а не при запуске add / upgrade ?

изменить: исправить опечатку

@ spencer-brown: судя по тому, что я видел, он действительно применяет оптимизацию при установке - вот что я считаю проблемным

Разве оптимизация yarn.lock не должна выполняться при добавлении пряжи? yarn.lock все равно будет изменен. Это вариант номер два в недавнем комментарии @artlogic , верно? Почему тогда не происходит оптимизация, и никто больше не должен фиксировать другое изменение yarn.lock?

@artlogic ой, опечатка :) - в моем комментарии должно быть написано "делает"; отредактировал.

Мы часто используем композитор, и composer install никогда не трогает файл блокировки.

composer update или composer require (эквивалент yarn add ) должны быть запущены для любых изменений или оптимизаций, которые необходимо внести в файл блокировки.

За многие годы нам никогда не приходилось беспокоиться о неоднозначном поведении composer install .

Я понимаю, что yarn выполняет несколько иную роль, но у композитора есть аналогичная проблема: вручную обновляются до composer.json и он выходит из синхронизации с файлом блокировки. В настоящее время composer install полностью игнорирует файл composer.json и выдает предупреждение.

Мы часто используем композитор, и composer install никогда не трогает файл блокировки.

composer update или composer require (эквивалент yarn add ) должны быть запущены для любых изменений или оптимизаций, которые необходимо внести в файл блокировки.

За многие годы нам никогда не приходилось беспокоиться о неоднозначном поведении composer install .

Я понимаю, что yarn выполняет несколько иную роль, но у композитора есть аналогичная проблема: вручную обновляются до composer.json и он выходит из синхронизации с файлом блокировки. В настоящее время composer install полностью игнорирует файл composer.json и выдает предупреждение.

Привет, дети, файл блокировки никогда не должен меняться при последующих установках. это просто тупо. если вы чувствуете, что оптимизация стоит того, чтобы ее коснуться, просто создайте вместо этого отдельный файл, который не входит в систему контроля версий.

Как и в случае с Gemfile.lock Bundler, весь смысл yarn.lock в том, что каждый раз, когда запускается yarn install, вы можете гарантировать детерминированные результаты во всех средах. Если yarn install изменяет файл блокировки, вы теряете эту гарантию. Другие команды, такие как yarn add или yarn update, очевидно, должны изменять yarn.lock, но yarn install - нет. Наша команда столкнулась с проблемами, когда у нас были немного разные версии пакетов, установленные в разных средах, что нам не нужно.

Я склонен думать, что yarn install --pure-lockfile должно быть значением по умолчанию, и может быть опция --fix-my-dev-process-inconsistencies-for-me-magically для получения текущего поведения.

@ryancastle --pure-lockfile не сообщит вам, что обновление предназначено для вашего файла блокировки. Он только его не генерирует. Это все еще может привести к неожиданному поведению. --frozen-lockfile завершится ошибкой, если требуется обновление.

Я уже некоторое время работаю с --install.frozen-lockfile true в моем .yarnrc и, похоже, он работает нормально. Хитрость заключается в том, чтобы создать начальный yarn.lock для репо без использования этого флага. После создания установки не могут изменить yarn.lock , но обновления могут. Как только я начал использовать этот рабочий процесс, количество случайных изменений в yarn.lock упало до нуля.

@artlogic Sidenote: Раньше у меня тоже было frozen-lockfile true в моем .yarnrc , теперь я применяю его только на сервере сборки, так как мы столкнулись с проблемами, которые были намеренно изменены в yarn.lock не были созданы, например, при попытке синхронизировать измененный package.json с yarn.lock , потому что разработчик вручную отредактировал package.json или использовал npm для добавления зависимостей.

См .: https://github.com/yarnpkg/yarn/issues/4570

Пример использования --frozen-lockfile значением по умолчанию с yarn install . Честно говоря, я не знаю, каким был бы хороший компромисс, чтобы не мешать людям, которые редактируют package.json а затем запускают yarn install для обновления файла блокировки. Я предложил флаг или новую команду, например yarn sync но идея должна быть конкретизирована, а затем оценена сообществом перед реализацией.

Более того, это будет критическое изменение, поэтому потребуется Yarn 2.x :)

флаг или новая команда, такая как синхронизация пряжи

звучит хорошо для меня 👍. и yarn install может показать уведомление «package.json и yarn.lock не синхронизированы. Запустите 'yarn sync', чтобы обновить файл блокировки»

Честно говоря, я не знаю, каким был бы хороший компромисс, чтобы не мешать людям, которые редактируют package.json, а затем запускают yarn install для обновления файла блокировки.

Я думаю, что в определенный момент необходимо принять решение о том, какой рабочий процесс подходит. Для меня включение этого почти кажется поощрением анти-паттерна.

Я предложил флаг или новую команду, такую ​​как синхронизация пряжи, но идея должна быть конкретизирована, а затем оценена сообществом перед реализацией.

Мне это кажется разумным компромиссом. Если вы настаиваете на ручном редактировании своего package.json , тогда имеет смысл запустить команду для восстановления синхронизации.

Вот что я бы хотел увидеть:

• yarn install без yarn.lock создает yarn.lock .
• yarn install с yarn.lock не изменяет его. Если он обнаруживает несоответствие между yarn.lock и package.json , возвращается ошибка (как указано @indeyets ).
• yarn sync (или, может быть, yarn install -s ) возвращает yarn.lock в синхронизацию с package.json .

У меня все еще есть основная проблема, заключающаяся в том, что yarn install изменяет yarn.lock даже если package.json не синхронизировано с файлом блокировки. Вы увидите выше, что он выполняет некоторые «оптимизации». Можно ли было хотя бы отключить это поведение без критических изменений?

У меня все еще есть основная проблема, заключающаяся в том, что установка пряжи изменяет yarn.lock, даже если package.json не синхронизирован с файлом блокировки. Вы увидите выше, что он выполняет некоторые «оптимизации». Можно ли было хотя бы отключить это поведение без критических изменений?

То же самое и здесь. Я думал, что это конкретная причина, по которой этот вопрос остается открытым. Поскольку "синхронизация" обсуждается в # 4147

Именно поэтому я в первую очередь искал эту проблему.

Объединим это и # 4147?

@BYK Я думаю, что почти все, что здесь обсуждалось, можно объединить с # 4147. Как я уже говорил ранее, я думаю, что меня все еще беспокоит "оптимизация", которую yarn install выполняет в yarn.lock даже если в package.json не произошло никаких изменений. .

Я считаю, что в качестве временного препятствия на пути к Yarn 2.0 эти оптимизации следует отключить. Я не думаю, что это будет серьезное изменение.

Я на 100% согласен с @artlogic .

Я настраивал CircleCI, и моя сборка продолжала давать сбой, и я проследил все до проблемы с кешированием с помощью yarn.lock . Исходя из Rails, я ожидал, что файл блокировки будет заблокирован командой установки.

Вот что предлагается для проверки кеша на 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
#...

Это никогда не сработает, потому что yarn.lock может измениться, а не должен.

К вашему сведению, на yarn 1.10.1 под macOS 10.13.6 я просто попробовал стимул ошибки OP и обнаружил, что yarn.lock не был изменен. Другими словами, когда я попробовал:

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

Итак, при использовании пряжи 1.10.1 yarn install не изменил yarn.lock , как это было для OP при использовании пряжи 1.0.1. (Я считаю это хорошей вещью, как и OP.)

@dtgriscom Замечательно , что проблема с Кордовой больше не возникает! Мне интересно, было ли это полностью исправлено или yarn все еще может попытаться оптимизировать файл блокировки при установке?

Было бы неплохо узнать, правда? Вы заметили, что проблема связана с конкретным пакетом; имеет смысл, что он также может зависеть от версии. (Я никогда не слышал оправдания «мы хотим изменить то, что не должно меняться»; кроме «мы оптимизируем» ...)

Я полностью согласен с тем, что операция install по умолчанию должна быть детерминированной. При обновлении файла .lock разработчик должен выполнить действие, которое, как он знает, приведет к изменению файла. Например, вы можете запустить что-то вроде yarn install --optimize что позволит провести небольшую оптимизацию, не нарушающую текущее состояние пакетов.

Добавление отдельных параметров, которые я должен искать в документации, чтобы я мог быть уверен, что мой файл блокировки не будет затронут без моего разрешения, довольно сбивает с толку, особенно если они могут вызвать сбой. Как разработчик я ожидаю, что у меня будет контроль над инструментами, которые я использую, и я чувствую, что такое поведение лишает меня этого.

Пожалуйста, пересмотрите вариант изменения поведения по умолчанию, чтобы не изменять файл блокировки и работать только с ним при установке зависимостей. Проверка целостности с предупреждением о том, что package.json не синхронизируется с файлом блокировки, - это все, что нужно людям.

Я говорил людям, что PR, включая изменения в файле блокировки, не будут объединены, поскольку файл блокировки изменяется только при добавлении новых или обновлении зависимостей. Вот что говорится в документации по установке :

yarn install

Установите все зависимости, перечисленные в package.json в локальную папку node_modules .

Файл yarn.lock используется следующим образом:

• Если присутствует yarn.lock и этого достаточно для удовлетворения всех зависимостей, перечисленных в package.json , будут установлены точные версии, записанные в yarn.lock , и yarn.lock изменится. . Yarn не проверяет наличие более новых версий.
• Если yarn.lock отсутствует или его недостаточно для удовлетворения всех зависимостей, перечисленных в package.json (например, если вы вручную добавляете зависимость к package.json ), Yarn ищет доступны новейшие версии, удовлетворяющие ограничениям в package.json . Результаты записываются в yarn.lock .

Если вы хотите убедиться, что yarn.lock не обновляется, используйте --frozen-lockfile .

Документация ошибочна, поскольку есть эти оптимизации, которые могут произойти, указанные выше, или это ошибка, которую следует принять во внимание на данный момент?

пс. это все еще происходит, и yarn --frozen-lockfile не терпит неудачи, когда это происходит.

В настоящее время я использую --frozen-lockfile в моем файле .yarnrc , который эффективно предотвращает изменение yarn.lock файла yarn при запуске yarn install на разных машинах. Но это также не позволяет yarn add blahblah изменять мой yarn.lock. Это правильное поведение или я что-то упускаю? Я прочитал всю цепочку, и мне кажется, что --frozen-lockfile - это рекомендуемый подход на данный момент?

@konekoya Да, вы правы, что вам НЕОБХОДИМО использовать

yarn install --frozen-lockfile

и не может полагаться на настройку в .yarnrc как это предотвратит обновление вашего yarn.lock .

В зависимости от содержания ваших .npmrc и .yarnrc вы можете использовать

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

но я бы не стал на это полагаться (поскольку он сломается, как только у вас появятся другие настройки в ваших rc-файлах.)

См. Мой комментарий и соответствующий выпуск: # 4570, особенно. мой вывод .

Спасибо за разъяснение @ k0pernikus. Вы просто сделали мой день :)

@BYK, почему yarn.lock на yarn install а не при запуске add / upgrade ?

Я думаю, что комментарий @spencer-brown является ключом к «исправлению» этой проблемы. Я только что проверил на себе и запустил yarn upgrade а затем yarn мне сказали: «Уже обновлено». Поэтому я удалил свой node_modules и запустил yarn что привело к "оптимизированному" файлу блокировки, который другие разработчики в моем проекте получили бы, если бы я нажал на тот, который получил от yarn upgrade .

Теперь, если бы yarn upgrade (и yarn add ) выполнял бы ту же оптимизацию, что и yarn install у нас вообще не было бы этой проблемы. Было много разговоров о нежелании нарушать какие-либо существующие функции, и я не считаю, что запуск оптимизации после yarn upgrade и yarn add что-либо нарушает - просто делает его немного медленнее.

В качестве обходного пути я думаю проинструктировать всех наших разработчиков удалять node_modules всякий раз, когда им нужно обновить файл блокировки, чтобы принудительно выполнить «оптимизацию», прежде чем передавать файлы блокировки другим. Или, может быть, они могут запустить yarn upgrade && yarn prune - может быть, это поможет?

В качестве обходного пути я думаю проинструктировать всех наших разработчиков удалять node_modules всякий раз, когда им нужно обновить файл блокировки, чтобы принудительно выполнить «оптимизацию», прежде чем передавать файлы блокировки другим. Или, может быть, они могут запустить yarn upgrade && yarn prune - может быть, это поможет

Обновление: вы не можете запустить prune вручную, вы просто получите следующее сообщение: _ "Команда prune не нужна. yarn install удалит посторонние пакеты" ._ И поскольку вы не можете запустить установку, потому что вы _ "Уже обновлены" _ Я предполагаю, что мы собираемся удалить node_modules и затем запустить yarn для сокращения.

Для меня самый большой аргумент в пользу yarn - это предсказуемое и надежное поведение файла блокировки. Изменение файла блокировки на yarn install вызывает у меня серьезное беспокойство.

Для меня самый большой аргумент в пользу yarn - это предсказуемое и надежное поведение файла блокировки. Изменение файла блокировки на yarn install вызывает у меня серьезное беспокойство.

Файл блокировки представлен как точная спецификация того, что будет установлено, поэтому нам не нужно беспокоиться о том, что будет установлено. Используйте один и тот же файл блокировки, и вы всегда будете получать одну и ту же установку. Но иногда yarn по собственной инициативе, по своим причинам и без предупреждения изменяет содержимое файла блокировки. Да, вы можете возразить, что «изменения файла не меняют то, что будет установлено», но зачем брать такую ​​четкую гарантию и путать ее? Зачем заставлять меня задуматься, следует ли мне повторно фиксировать измененный файл блокировки? Почему запятнали свою главную претензию на славу?

Это действительно невероятно. Другие уже хорошо об этом заявили. Файл блокировки не должен изменяться при установке. Это негативно влияет на рабочие процессы фиксации. Каждый разработчик в нашей команде знает, при каких обстоятельствах файл блокировки может изменяться. Когда файл блокировки изменяется без обновления зависимостей, это вызывает ненужную путаницу и дополнительную проверку. Это базовый UX менеджера пакетов, который просто сломан. Пожалуйста исправьте.

Я просто удивился такому поведению, когда при переходе с Node.js 13 на 14 все мои файлы yarn.lock изменились при выполнении yarn install и мне было интересно, почему ...

Я думаю, что правильным поведением будет выдавать предупреждение, если каким-либо образом _оптимизировать_ файл yarn.lock .