Yarn: сделать `--pure-lockfile` по умолчанию для` install`

Я согласен. Следует обсудить, почему yarn install записывает файл блокировки по умолчанию в первую очередь, поскольку это, похоже, противоречит всей концепции файла блокировки. Зачем нужен файл блокировки, если по умолчанию он не блокирует версии?

Есть случай, когда yarn install создает файл блокировки, если его нет, то есть когда кто-то конвертирует проект для использования yarn , но причины для постоянного написания этого файла не ясны. Я согласен с мнением @bestander , что только мутирующие действия должны обновлять файл блокировки по умолчанию, т.е. add/upgrade/remove .

Должен ли быть способ изменить файл блокировки без add/remove/upgrade ex: в сценарии, когда вы обновляете Yarn и он использует новую версию файла блокировки?

Я полагаю, вариант можно было бы перевернуть

yarn install --save-lockfile

17 октября 2016 г. в 18:53 Джеймс Айд написал на [email protected] :

Если есть способ изменить файл блокировки без добавления / удаления / обновления
Пример: в сценарии, когда вы обновляете Yarn, и он использует новый файл блокировки
версия?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/yarnpkg/yarn/issues/570#issuecomment -254282256 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ACBdWJLpdvqiwcBwqE4KB3x3f4oCn_nVks5q07YYgaJpZM4KSlSw
.

Меня это тоже смущает. В чем причина текущего поведения по умолчанию?

Afaik, для поведения по умолчанию не было веских причин.
Идея, я полагаю, состоит в том, чтобы сохранить файлы блокировки людей «вечнозелеными».

Кстати, PR приветствуется

Я думаю, причина в том, что пряжа изначально была разработана с помощью одной команды install которая была разделена на install/add/upgrade

Итак, чтобы проверить, правильно ли я это понимаю:

yarn устанавливает все зависимости, а также изменяет файл блокировки. На сервере CI вы должны использовать yarn install --pure-lockfile ?
Почему файл блокировки изменяется во время установки? Поскольку вы ничего не обновляете ... Yarn должен просто установить пакеты, как описано в файле блокировки, верно?

Спасибо за объяснение!

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

@kittens Разве файл блокировки не должен обновляться только при добавлении / удалении / обновлении каких-либо пакетов? Они всегда должны обновлять файл блокировки, а также выполнять первоначальную установку.

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

Эта проблема зависит от того, что вы считаете основной задачей диспетчера пакетов.

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

С npm у меня было много случаев, когда разработчики присоединялись к проекту, только чтобы обнаружить, что проект не работает на их машине. Эти случаи произошли из-за переходных зависимостей, переводящих версии в версии с критическими изменениями или просто не следующих за semver. Я надеялся, что yarn решит эти проблемы, но если вывод состоит в том, что все разработчики проекта должны запускать yarn install --pure-lockfile чтобы быть на 100% уверенными в том, что проект будет построен, тогда это не так. дело.

Другая роль диспетчера пакетов - это предоставление проектам контроля над своими зависимостями. Если по умолчанию он сделан чистым, разработчики могут взглянуть на yarn outdated чтобы увидеть устаревшие версии, а затем просмотреть примечания к изменениям, избегая любых критических изменений. Это дало бы разработчикам полный контроль над тем, чтобы запускать только версии в заданные сроки выпуска, вместо того, чтобы запрещать разработчикам делать git commit -a чтобы избежать случайных коммитов файла блокировки.

Я согласен со всем, что говорит

Совершенно удивили нас, прервав сборку после того, как мы начали использовать yarn в течение нескольких дней. Я честно подумал, что --pure-lockfile было поведением по умолчанию после прочтения большей части документации и о том, чем это лучше, чем npm с термоусадочной пленкой. Пожалуйста, сделайте дефолт :)

@ide Представьте себе сценарий, в котором кто-то просто использует npm и обновляет package.json , как будет обновляться yarn.lock ?

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

Подробнее о вышесказанном: наша сборка содержит coffeescript из Github в качестве подзависимости. coffeescript подтолкнул несколько коммитов, и мы получили измененный yarn.lock в нашем процессе сборки, запустив всего 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"

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

Я воспринимаю yarn install как команду, которая создает для меня node_modules.
Это противоположно yarn add и yarn remove которые изменяют package.json, yarn.lock и cleanup node_modules.
В отличие от add и remove я использую install 100 раз чаще, особенно в CI, где я никогда не ожидаю появления побочных эффектов.

Примеры, когда я не ожидаю, что что-то изменится:

1. Я использую Yarn 0.15.0, мои товарищи по команде используют Yarn 0.16.0.
   Поскольку 0.16.0 добавлял пробелы между записями в yarn.lock каждый раз, когда я запускаю yarn install против yarn.lock, который был сгенерирован моими товарищами по команде, я получаю измененный файл yarn.lock, который мне нужно помнить, чтобы не фиксировать.
   Наоборот.
2. Другие мои инструменты сборки зависят от yarn.lock как «источника истины» состояния node_modules. Если он изменится неожиданно, я получу недетерминизм в моих сборках

@kittens

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

Представьте себе сценарий, в котором кто-то просто использует npm и обновляет package.json, как будет обновляться yarn.lock?

Если мы предположим, что yarn install не должен обновлять yarn.lock , тогда он также должен завершиться ошибкой, если yarn.lock не синхронизируется с package.json чтобы подчеркнуть тот факт, что yarn install --save-lockfile необходимо для восстановления синхронизации.

Установка +1 пряжи не должна изменять yarn.lock

1. Отладчик - это приложение oss. Мы хотим, чтобы участники могли пряжу установить и получить _хорошие_ версии. У нас есть люди, которые устанавливают npm и говорят, что он ломается из-за транзитивных свойств. При установке пряжи участники пряжи устанавливают и не знают, что делать с изменениями замка пряжи.

Меня не волнует обновление файла блокировки. В идеале greenkeeper будет делать это при изменении deps, и тогда мы могли бы объединить изменения файла блокировки.

Я хочу обновить эту проблему с учетом текущих мыслей по этому поводу. @kittens и я оба думаем, что --pure-lockfile должно _не_ быть значением по умолчанию по нескольким причинам.

Все начинается с того, как люди добавляют / удаляют / обновляют зависимости. Несмотря на то, что для этого есть команды, обычной практикой является ручное обновление package.json вручную или с помощью другого инструмента, такого как Lerna .

После того, как вы вручную изменили package.json ожидание как в Yarn, так и в npm таково, что при запуске другой установки он будет _syncs_ с package.json . В этом смысле yarn install можно почти переименовать в yarn sync .

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

Ваш package.json - это окончательный источник истины, это ваш интерфейс для yarn, ваша конфигурация и единственное, о чем вы должны когда-либо беспокоиться. В идеальном мире вы просто вкладываете свои yarn.lock и никогда больше не должны об этом думать.

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

Использование --pure-lockfile по умолчанию не означает, что Yarn не дает последовательных и надежных результатов. Тот же package.json приведет к тому же yarn.lock что приведет к тому же node_modules 100% времени.

Когда вы обновляете package.json обновляется ваш yarn.lock файл, а затем обновляется node_modules . Это очень естественный порядок вещей, и мы должны его придерживаться

Что касается возможности CI получать разные зависимости, когда вы обновили свой package.json но не запустили yarn install для синхронизации всего, что, я уверен, кто-то поднимет (хотя я не вижу, как проблема) - я и другие говорили с различными инструментами CI об интеграции Yarn, мы можем легко заставить их использовать --pure-lockfile по умолчанию, если люди видят в этом большую проблему.

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

@thejameskyle Я был бы признателен, если бы вы кое-что прояснили:

1. У разработчика есть package.json который содержит зависимость "foo": "^1.0.0"
2. Разработчик запускает yarn install . Пакет foo в настоящее время имеет версию 1.0.0 , поэтому он создает файл yarn.lock который блокируется в [email protected]
3. Разработчик добавляет в Git yarn.lock .
4. Разработчик запускает модульные тесты на своей локальной копии репо, все работает нормально.
5. Разработчик отправляет свое репо в CI (например, Travis).
6. CI запускает yarn install , но foo теперь обновлен до версии 1.1.0 , поэтому Yarn устанавливает [email protected] и перезаписывает yarn.lock новой версией foo
7. CI ломается, потому что foo имеет критическое изменение в версии 1.1.0

Вот похожая ситуация:

1. У разработчика есть package.json который содержит зависимость "foo": "^1.0.0" , которая заблокирована как [email protected] , а yarn.lock сохраняется в Git.
2. Модульные тесты отлично работают с локальной копией репозитория разработчика.
3. Участник клонирует репо с намерением сделать модификацию + пул-реквест.
4. Когда участник запускает yarn install он получает версию [email protected] которая вызывает обновление yarn.lock .
5. Теперь сборка участника не работает, потому что foo имеет критическое изменение в версии 1.1.0

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

Итак, если бы вы могли уточнить, что текущее поведение yarn install не имеет перечисленных выше проблем, я думаю, это устранило бы большинство наших опасений. : +1:

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

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

Но у него плохое поведение, если зависимость устанавливается из github, как я сообщал выше.

@adamchainz Это должно быть исправлено отдельно, мы можем легко заблокировать его для фиксации

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

@thejameskyle : Я не уверен, что понимаю, почему это не настоящий сценарий. Не могли бы вы уточнить?

Представьте себе функцию memoize, в которой входом является package.json а на выходе - yarn.lock .

1. В первый раз, когда вы передаете package.json он создает yarn.lock и кеширует результат.
2. В следующий раз, когда вы запустите _that same_ package.json результат будет точно таким же, потому что он кэширован.
3. Когда вы меняете package.json вы аннулируете кеш, и теперь yarn.lock будет пересчитан.

Сейчас мы говорим об избавлении от # 3 и вместо этого обращаемся с yarn.lock как если бы он не был признан недействительным из-за измененного package.json . Что было бы действительно странно для функции memoize и было бы действительно странным поведением для Yarn.

Что происходит с пакетом с точки зрения коммитов и новых версий _должно_ не иметь значения (если у нас есть ошибка с коммитами git, мы должны исправить это отдельно, но это не связано с этой проблемой).

Это сложнее, чем я себе представлял (каждая версия пакета эффективно «запоминается» индивидуально, изменение версии одного пакета не аннулирует остальные), но, надеюсь, теперь все понимают суть.

@thejameskyle : Для ясности (и любопытства) допустим, у меня есть проект с файлом yarn.lock , и кто-то срывает репозиторий. Без запуска yarn install или npm install этот человек добавляет новую зависимость к файлу package.json а затем запускает yarn install . Будет ли в этом случае полностью проигнорирован существующий файл yarn.lock ?

Здесь происходит куча разных вещей, которые я хотел попытаться разгадать (без каламбура).

Во-первых, люди выдвинули ряд различных требований, которые я считаю бесспорными (и которые вносят некоторые из существующих ошибок поведения, о которых я скоро доберусь).

Из исходного отчета об ошибке.

Согласованность теряется, когда файл блокировки изменяется в зависимости от среды (установленная в настоящее время версия yarn).
Какое ожидаемое поведение?
Не пишите yarn.lock или package.json при установке пряжи.
Чтобы обновить yarn.lock, используйте yarn upgrade

Точнее, ожидаемая семантика, на мой взгляд, такова:

• если package.json не изменилось с момента последнего изменения yarn.lock , yarn.lock является источником истины и не подлежит обновлению.
• если package.json изменилось с последнего раза, yarn.lock изменилось, обновите yarn.lock чтобы оно удовлетворяло package.json и обновите node_modules .
• если yarn update запущен, повторно разрешите все зависимости и получите последнюю версию всего, что удовлетворяет package.json .

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

Если это не текущее поведение пряжи, я считаю, что это ошибка.

@esphen написал:

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

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

Я согласен с мнением @bestander , что только мутирующие действия должны обновлять файл блокировки по умолчанию, то есть добавлять / обновлять / удалять.

Основная проблема здесь заключается в том, должно ли изменение package.json вызывать обновление yarn.lock . На мой взгляд, если изменение package.json не удовлетворяет yarn.lock , оно должно обновить yarn.lock .

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

Для большинства пользователей лучший способ думать о файле блокировки - это то, что это артефакт текущей пряжи, который представляет точные версии всех пакетов, которые использовались для текущего package.json . Регистрируя его, другие участники, CI и производственный код могут использовать те же версии.

@Guuz сказал:

Итак, чтобы проверить, правильно ли я это понимаю:
yarn устанавливает все зависимости, а также изменяет файл блокировки. На сервере CI вы должны использовать yarn install --pure-lockfile?

Этот вопрос перекликается с мнением нескольких человек, высказанных в этой теме.

Cargo имеет флаг --locked который говорит: «Если package.json не удовлетворяет yarn.lock , это серьезная ошибка». У Bundler есть аналогичный флаг ( --frozen ), который был добавлен, когда Heroku принял Bundler, чтобы выдавать людям серьезную ошибку, если они внесли локальные изменения в свои Gemfile и забыли проверить Gemfile.lock .

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

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

@esphen сказал:

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

Я считаю, что это бесспорно.

С npm у меня было много случаев, когда разработчики присоединялись к проекту только для того, чтобы обнаружить, что проект не работает на их машине. Эти случаи произошли из-за переходных зависимостей, переводящих версии в версии с критическими изменениями или просто не следующих за semver. Я надеялся, что yarn решит эти проблемы, но если вывод состоит в том, что все разработчики проекта должны запускать yarn install --pure-lockfile, чтобы быть на 100% уверенными в том, что проект будет построен, то это не так.

Запуск yarn install --pure-lockfile будет означать, что файл блокировки будет соблюдаться, даже если версии внутри файла блокировки конфликтуют с версиями, указанными в package.json . Это должно возникнуть только в первую очередь, если разработчик забывает проверить свои yarn.lock после внесения изменений в package.json .

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

Если package.json не изменилось, на мой взгляд, это ошибка, если yarn.lock обновляется. По крайней мере, один случай ошибки указан в исходном отчете:

lockfile изменяется в зависимости от среды (установленная в настоящее время версия yarn).

Я считаю, что это ошибка, и ее нужно исправить.

Позже в теме @thejameskyle сказал:

Представьте себе функцию memoize, в которой входом является package.json, а выходом - yarn.lock.

На мой взгляд, это именно та ментальная модель (« yarn.lock может измениться тогда и только тогда, когда изменилось package.json »), и если абстракция просочится, мы должны это исправить.

@adamchainz сказал:

Подробнее о вышесказанном: наша сборка содержит coffeescript из Github в качестве подзависимости. coffeescript подтолкнул несколько коммитов, и мы получили модифицированный yarn.lock в нашем процессе сборки, запустив только yarn install

и позже:

Но у него плохое поведение, если зависимость устанавливается из github, как я сообщал выше.

Проблема здесь в том, что yarn не рассматривает git sha как часть заблокированной версии зависимостей git. У Cargo и Bundler есть концепция «точной» версии, которая сериализуется в файл блокировки; для источников git "точной" версией является SHA. Затем, когда вы создаете новый клон с помощью всего лишь package.json и yarn.lock и запускаете yarn , вся информация, необходимая для получения именно того кода, который вам нужен.

Должен признаться, что я пропустил это взаимодействие при просмотре исходного кода git; в коде есть отслеживание SHA, но yarn install не гарантирует, что гидратированный граф зависимостей его уважает.

TL; DR

Я согласен с @thejameskyle и @kittens, что yarn.lock следует синхронизировать с package.json автоматически, потому что я считаю, что пользователи должны иметь возможность предполагать, что версии, указанные в их package.json соответствуют тому, что используется при выполнении их приложения.

Однако, похоже, есть несколько ошибок, которые вызывают несоответствующий отток в yarn.lock даже если package.json не изменился:

• изменение версии пряжи на разных машинах обновляет файл блокировки
• зависимости git обновляются, даже если package.json не обновляется, что затем обновляет файл блокировки

Мы также должны рассмотреть что-то вроде флага Cargo --locked , который вы можете использовать в CI для быстрого сбоя сборки, если разработчик обновляет package.json и забывает проверить обновленный yarn.lock .

@thejameskyle Спасибо! : heart: Я согласен с вами и @kittens, что yarn.lock следует обновить после изменения package.json

@wycats Как --locked (или подобного). Мы должны создать новый выпуск об этом.

Сделано # 1568 для отслеживания проблемы с Git SHA

@wycats , спасибо за разгадывающий, очень содержательный обзор!

Это означает, что когда репозиторий впервые клонируется на машине, если yarn.lock был зарегистрирован, yarn всегда должен рассматривать его как источник истины, а не генерировать обновления yarn.lock и переходить непосредственно к этапу выборки.
Если это не текущее поведение пряжи, я считаю, что это ошибка.

Именно по такому сценарию был открыт этот вопрос.
У нас есть несколько активных версий Yarn, и я не думаю, что в нашем масштабе мы сможем делать атомарные обновления повсюду.
Сборки на основе пряжи 0.13, 0.14 и 0.15 внесли небольшие изменения в файлы yarn.lock, хотя package.json был синхронизирован.
Это вызвало несколько проблем, например, сборки Buck замедлились, потому что изменения в исходном дереве сделали кеши недействительными.
Это заставило меня и пару команд поработать несколько часов.

@thejameskyle , спасибо, что поделились своим мнением.
Я не считал, что сценарий package.json не синхронизирован с yarn.lock, чтобы быть справедливым. И у вас есть веская точка зрения.

Однако, как указал @wycats , исходный отчет об ошибке действителен.
Это важно для правильных сборок, и я снова открою проблему с намерением найти решение, которое удовлетворит все заинтересованные стороны.

@wycats

Точнее, ожидаемая семантика, на мой взгляд, такова:

• если package.json не изменилось с момента последнего изменения yarn.lock , yarn.lock является источником истины и не подлежит обновлению.
• если package.json изменилось с последнего раза, yarn.lock изменилось, обновите yarn.lock чтобы оно удовлетворяло package.json и обновите node_modules .
• если yarn update запущен, повторно разрешите все зависимости и получите последнюю версию всего, что удовлетворяет package.json .

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

Мы следуем этой семантике, которую я добавил в № 364.

@bestander Вы участвовали в PR (# 364), чтобы применить эту эвристику. Какие дополнительные изменения вы предлагаете?

Это очень серьезная проблема, и мы уже договорились, что --pure-lockfile будет значением по умолчанию, и мы будем следовать эвристике, описанной @wycats. Если эта проблема должна быть оставлена ​​открытой, тогда заголовок должен отражать текущую проблему с таким поведением.

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

Можем ли мы перейти к новому выпуску? Этот комментарий здесь можно просто сохранить в виде архива.

Звучит хорошо, @thejameskyle , сегодня я создам новый выпуск и добавлю сюда ссылку

Создан новый тематический выпуск https://github.com/yarnpkg/yarn/issues/1576

Было бы интересно иметь возможность сделать yarn install неуспешным, если пакет в package.json не находится в yarn.lock, т.е. сбой, если какой-либо пакет не заблокирован

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

tldr; Несвязанные изменения в package.json не приведут к обновлению пакета до последней версии, совместимой с его неизмененным семвером package.json .

Основываясь на некоторых из приведенных выше формулировок, это звучало так, как будто yarn.lock было кешировано с ключом на хеш-коде package.json , и, следовательно, звучало так, как будто yarn.lock будет записано в (обновлено / кеш аннулирован ) при любом изменении package.json , что будет проблематично, поскольку несвязанное изменение (например, обновление до "description" или другой зависимости) может привести к обновлению версии этой зависимости yarn.lock до более новая версия в той же существующей package.json semver.

Однако я подтвердил, что запись пакета yarn.lock записывается только тогда, когда обновляется соответствующий package.json semver (даже если новый semver совместим с существующей версией yarn.lock , и следовательно, в противном случае не потребовалось бы обновления версии).

Например,

• Скажите yarn add lodash@^4.17.1 installs [email protected]
• Позже доступен [email protected] .
• yarn продолжит установку [email protected]
• Если / Пока версия lodash не будет изменена в package.json (или yarn add / upgrade / remove запускается специально для lodash).

Панировочные сухари # 1576

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

@CrabDude, спасибо, что поделились своим разъяснением.

Вы имеете в виду - в приведенном выше примере - что только lodash и его собственные зависимости будут обновлять свои версии блокировки в yarn.lock ? например, даже если у другой зависимости может быть новая версия блокировки, она не будет обновляться одновременно?

Или второй пример: допустим, yarn.lock сильно устарел, и пользователь запускает yarn add чтобы добавить новую зависимость в package.json. Будут ли теперь обновлены все остальные устаревшие пакеты в yarn.lock или они останутся прежними?

@rarkins

Вы имеете в виду - в приведенном выше примере - что только lodash и его собственные зависимости будут обновлять свои версии блокировки в yarn.lock?

да. Это подтверждается моим примером.

Будут ли теперь обновлены все остальные устаревшие пакеты в yarn.lock или они останутся такими же?

Казалось бы, не lodash деревья зависимостей / записи блокировки пакетов не будут обновлены; будут только подчиненные зависимости lodash .

С моей точки зрения, все это желательно и ожидаемо.

Предисловие : Я люблю пряжу. Но меня это безмерно расстраивает.

В моей компании yarn install постоянно меняет файл блокировки на разных машинах (на каждой работает одна и та же версия), несмотря на то, что никогда не менял package.json . И когда мы это делаем, мы обновляем, используя yarn add . Это раздражает, потому что CI проверяет, что статус git является чистым после сборки, чтобы убедиться, что мы не забыли сделать такие вещи, как проверка файла блокировки, и он часто меняется.

Я ожидал, что пряжа обеспечит одинаковые модули node_modules на всех машинах _по умолчанию_. Не с лишними флажками. Правильность будет важнее удобства. Если мне нужна была неопределенность, я мог использовать npm напрямую. Когда файл изменяется, это для меня сигнал о том, что что-то изменилось, и я должен внимательно его изучить. Это не должно измениться.

Вопросов

• Говорят, что, несмотря на изменение файла блокировки, содержимое node_modules всегда будет идентично тому, когда оно было сгенерировано? Я не верю, что это так, но если это так, то я понимаю путаницу в этой теме - это будет означать, что пряжа делает правильные вещи, несмотря на то, что на вид это не так.
• При изменении package.json файл блокировки создается заново. Разве это не могло непреднамеренно изменить множество зависимостей в зависимости от состояния node_modules этого конкретного программиста? Пряжа должна определять дельту и стараться как можно лучше сохранить существующие блокировки (если это еще не сделано).
• Почему yarn add указывает версии в package.json с ^ ? Опять же, я понял, что yarn обещала заморозить зависимости.

Связанные ошибки

• Когда случайный пакет удаляется в node_modules , yarn install сообщает об успешном выполнении без переустановки. Когда многие из них исчезают, он переустанавливает их. npm в этом отношении более тщательно.
• Файл блокировки имеет тенденцию к восстановлению, если вы удалите node_modules и выполните чистую установку (что буквально противоположно тому, что вы ожидаете - я ожидаю, что он установит именно то, что находится в файле блокировки, и больше ничего не сделает)
• Если вы удалите файл блокировки, не касаясь пакета или node_modules после чистой установки, yarn регенерирует его, и он обычно сильно отличается от предыдущей версии. Это похоже на то, что компилятор каждый раз создает другой код, несмотря на то, что ничего не меняет.

В целом, yarn ускоряет установку, но, похоже, терпит неудачу в своей основной (не) компетенции: постоянное замораживание версий по умолчанию. Мне не нужны удобства, которые помогут мне начать мой проект, мне нужна помощь огромной команды в его поддержке на протяжении многих лет. Программисты умны и целенаправленны, когда они хотят изменений, они прямо спрашивают.

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

@jspiro , спасибо, что написали это.
Здесь подняты несколько вопросов.
Лучше открывать каждый выпуск отдельно, иначе они будут потеряны в комментариях.

Вы используете последнюю версию Yarn?
Начиная с версии 0.18-0.19 мы не видим изменений файлов yarn.lock между машинами.

Вопросов:

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

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

При изменении package.json файл блокировки создается повторно. Разве это не могло непреднамеренно изменить множество зависимостей в зависимости от состояния node_modules этого конкретного программиста? Пряжа должна определять дельту и стараться как можно лучше сохранить существующие блокировки (если это еще не сделано).

Это хороший запрос функции, хотелось бы увидеть PR за это.

Почему yarn add указывает версии в package.json с помощью ^? Опять же, я понял, что yarn обещала заморозить зависимости.

Это отражает поведение npm.
Вы можете сделать yarn add [email protected] или yarn add is-array --exact для точной версии.
Может быть, в какой-то момент мы должны сделать точные версии по умолчанию, это может быть обсуждено в RFC.

Когда случайный пакет удаляется в node_modules, yarn install сообщает об успехе без переустановки. Когда многие из них исчезают, он переустанавливает их. npm в этом отношении более тщательный.

По умолчанию пряжа проходит быструю поверхностную проверку.
Выполнение более глубокой проверки будет медленнее, но мы работаем над этим, у меня есть идея, как мы могли бы сделать быструю глубокую проверку.
Однако вы не должны касаться файлов в node_modules, проверка каждого файла на предмет модификации приведет к очень медленной установке.
Если вы хотите пропустить мелкую проверку, удалите файл node_modules/.yarn-integrity перед установкой. Это не официально и может быть изменено.
Официальный способ - запустить yarn install --force , это вызовет полную установку, но в качестве побочного эффекта перепишет yarn.lock.

Файл блокировки имеет тенденцию к восстановлению, если вы удалите node_modules и выполните чистую установку (что буквально противоположно тому, что вы ожидаете - я ожидаю, что он установит именно то, что находится в файле блокировки, и больше ничего не сделает)

Давно не видел этого.
Откройте проблему и отправьте мне копию, если это можно воспроизвести.

Если вы удалите файл блокировки, не касаясь package или node_modules после чистой установки, yarn восстанавливает его, и обычно он сильно отличается от предыдущей версии. Это похоже на то, что компилятор каждый раз создает другой код, несмотря на то, что ничего не меняет.

Через некоторое время могли быть выпущены новые версии транзитивных зависимостей.
Из-за этого структура node_modules может значительно измениться из-за логики подъема.
Это работает так, как задумано.
Приходит команда import https://github.com/yarnpkg/yarn/pull/2580.
Это позволит вам создать файл блокировки из существующих модулей node_modules.

@jspiro , Yarn - это молодой проект, управляемый сообществом, и мы приветствуем ваши пиарщики, чтобы он лучше работал на вас.

Есть ли шанс получить хотя бы возможность установить желаемое поведение по умолчанию?

В настоящее время мы исправляем эту проблему https://github.com/yarnpkg/yarn/issues/3490 , иногда yarn install может привести к оптимизации файла блокировки, что не является ожидаемым поведением, и мы исправим это.
Это может быть причиной, по которой вы запрашиваете это изменение, в противном случае файл yarn.lock должен измениться только в том случае, если вы вносите изменения в package.json вручную.

Вы можете установить для --pure-lockfile / - frozen-lockfile значение true в .yarnrc, и оно будет добавлено к команде установки по умолчанию:

--install.pure-lockfile true

Моя проблема в том, что если я не использую чистый файл блокировки, я получаю неправильную версию установленных зависимостей. Это не связано с нежелательными изменениями yarn.lock

Можете ли вы сообщить о проблеме с повторными этапами?
Мы разберемся

Меня это тоже укусило, когда package.json и yarn.lock вышли из синхронизации из-за того, что разработчик по ошибке добавил зависимость через npm install --save вместо yarn add .

Я не согласен с тем, что pure-lockfile должен быть значением по умолчанию, и утверждаю, что frozen-lockfile должно быть значением по умолчанию для yarn install .

Поскольку frozen-lockfile выдает сообщение об ошибке, если yarn.lock и package.json не синхронизированы. Таким образом, frozen-lockfile очень полезен на машине сборки (например, jenkins), поскольку он помечает эту сборку, как и следовало ожидать, как сбой.

Затем разработчик должен решить, какую версию добавить в package.json / yarn.lock.

К сожалению, по умолчанию yarn install просто получит самую последнюю версию еще не заблокированных зависимостей и напишет обновленную версию yarn.lock , которая никогда не будет частью проекта. Следовательно, возможны будущие перерывы в сборке из-за неожиданного скачка версии. Именно по этой причине у нас есть файл блокировки.

Однако суть должна быть такой:

Только такие команды, как add , remove и upgrade должны изменять yarn.lock .

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

Таким образом, замороженный файл блокировки очень полезен на машине сборки (например, jenkins), поскольку эта сборка не удастся.

Я думаю, мы можем включить это автоматически, когда обнаружим, что находимся в режиме CI?

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

Я бы сказал открыть новую ☺️

Я согласен с @thejameskyle и @kittens, что yarn.lock должен автоматически синхронизироваться с package.json.

Не уверен, что это было сказано, но на всякий случай: вам не нужно аннулировать весь yarn.lock, когда что-либо в package.json изменяется. Вы можете сделать недействительными только зависимости только тех пакетов, которые были изменены внутри package.json. Например, если вы обновили только TypeScript, зависимости TypeScript необходимо будет изменить (с учетом других неизмененных пакетов).