Пряжа: использовать yarn.lock зависимостей

Я использую пряжу для установки пакетов непосредственно из GitLab компании:

yarn add git+ssh://<user>@<host>:<repo>

Для зависимостей первого уровня я использую yarn --pure-lockfile реконструировать мой node_modules в соответствии с yarn.lock,

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

Так скажем, я зависим от A который тестируется с определенной версией B, В package.json Я не указываю версию, но она содержится в yarn.lock,

Когда я сейчас устанавливаю пакет A пряжа получит последнюю версию B несмотря на запись в A/yarn.lock

Я знаю, что могу решить эту проблему, передав конкретную версию в A/package.json (по крайней мере, я думаю).

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

Источник

1 ответ

TLDR:

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

Давайте сначала проясним некоторые вещи:

  1. --pure-lockfile такой же, как обычная установка пряжи, за исключением того, что она не будет генерировать yarn.lock файл или обновить один, если присутствует.
  2. Пряжа всегда читает из yarn.lock по умолчанию для разрешения зависимостей при установке, если не поставляется с --no-lockfile, Таким образом, нет необходимости говорить это читать yarn.lock,

Что такое yarn.lock используется для?

yarn.lock используется для решения того, что version должны быть получены с учетом semver version модуля в package.json, Не используется для определения того, что semver version следует ли разрешить модуль в. Это просто не его вариант использования.

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

Для этого пряжа использует yarn.lock файл в корне вашего проекта.

Итак, для решения semver version зависимости, пряжа всегда зависит от package.json, Для данного semver version пряжа проверяет yarn.lock файл, чтобы увидеть, что version если это принесет. Это то, что делает пряжу детерминированной (та же техника используется npm который использует npm-shrinkwrap.json).

Пример: Semver Версии как ^1.2.4 можно разрешить на любой номер версии, который >= 1.2.3 and < 2.0.0, Без пряжи npm установится 1.2.4 в одной машине но 1.9.9 в другой машине, в зависимости от последней версии, присутствующей на момент установки. Это проблема, которую пряжа решает, используя yarn.lock,

semver version определяется package.json файл. yarn.lock Файл - это только поиск, для которого требуется установить версию и коммит хеша для данного semver version число.

Как пряжа разрешает версию модуля с учетом его полуверсии?

Предположим, что в настоящее время наш файл yarn.lock выглядит так:

bluebird@2.9.6:
  version "2.9.6"
  resolved "https://<...>/bluebird-2.9.6.tgz#1fc3a6b1685267dc121b5ec89b32ce069d81ab7d"

bluebird@^2.9.30:
  version "2.11.0"
  resolved "https://<...>/bluebird-2.11.0.tgz#534b9033c022c9579c56ba3b3e5a5caafbb650e1"
...
myModule@5.1.0:
  version "5.1.0"
  resolved "https://<...>/moduleA-5.1.0.tgz#ce97130858add59d616ee80675383b0c127290a0"
  dependencies:
    bluebird "^1.0.0"
  1. Если package.json имеет bluebird: "^2.9.30", пряжа ищет запись bluebird@^2.9.30 в файле блокировки. Это присутствует и, следовательно, решено version=2.11.0,
  2. Если package.json имеет bluebird: "^2.9.0", пряжа ищет запись bluebird@^2.9.0 в файле блокировки. Этого нет. Предположим, что последняя стабильная версия, которая удовлетворяет критериям semver, 2.13.0, тогда пряжа добавляет запись для bluebird@^2.9.0, решено 2.13.0, При разрешении версии для данного semver version для bluebird не имеет значения, какая запись присутствует для bluebird в зависимостях moduleA в файле блокировки.

Semver Version не зависит от того, какие записи присутствуют в карте зависимостей для модуля в yarn.lock файл.

Итак, если package.json имеет bluebird: "", пряжа ищет запись bluebird@ в файле блокировки, но не может его найти. Следовательно, это решает bluebird: "" до последней версии, предположим 3.5.0, Теперь пряжа добавит запись для bluebird@ решено 3.5.0,

bluebird@:
  version "3.5.0"
  resolved "https://<...>/bluebird-3.5.0.tgz#d9551f9de98f1fcda1e683d17ee91a0602ee2eb9"

Форма теперь на всякий раз, когда пряжа сталкивается {bluebird: ""}, он найдет запись для bluebird@ в файле блокировки и, следовательно, всегда будет разрешать его 3.5.0,

Решение вашей проблемы

Разрешить B: "" к версии сказать 1.0.0, вам нужно иметь запись для B@ в yarn.lock решено 1.0.0, Однажды, yarn.lock есть запись для B@ все последующие установки всегда будут получать версию 1.0.0 за B="",

Ниже приведены шаги, которые необходимо предпринять, чтобы сделать то же самое:

Подход 1 (рекомендуется)

Если вы хотите, чтобы B разрешил до последней версии:

  1. добавлять B:"" в упаковке A.json
  2. Бежать yarn install, Это добавит запись для B@ разрешено до последней версии.
  3. От себя yarn.lock файл.
  4. Форма теперь на том, кто бежит yarn install получит ту же версию.

Подход 2

Если вы хотите, чтобы B имел более старую версию: (Настоятельно не рекомендуется)

  1. добавлять B: 1.0.0 в пакете A.json.
  2. Бежать yarn install, Это добавит запись B@1.0.0 в файле блокировки.
  3. добавлять B@ рядом B@1.0.0 в пряжи. B@, B@1.0.0: ...
  4. Изменить версию B на "" в пакете A.json.
  5. От себя yarn.lock файл.
  6. Форма теперь на том, кто бежит yarn install получит версию B как 1.0.0,

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

Подход 3 (рекомендуется)

Если вы хотите, чтобы B остался на 1.0.0

  1. Исправить версию B в 1.0.0 в пакете A.json.
  2. Бежать yarn install, Это добавит запись B@1.0.0 в файле блокировки.
  3. Push-файл yarn.lock
  4. Форма теперь на том, кто бежит yarn install получит версию B как 1.0.0,

Изменить: Использование файла yarn.lock, присутствующего в зависимостях

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

В настоящее время нет способа заблокировать зависимости второго уровня, используя в них yarn.lock. Я не вижу в этом необходимости. На самом деле создатели пряжи объясняют, почему это так. Причины:

  1. Версии, которые должны быть установлены для зависимостей второго уровня, могут быть хорошо записаны в файле yarn.lock верхнего уровня, как я объяснил выше.
  2. Вы никогда не сможете обновить версии зависимостей в вашем собственном приложении при их непосредственном использовании, поскольку они будут заблокированы другими файлами yarn.lock. В этом можно убедиться, объяснив, как пряжа разрешает зависимости.
  3. Yarn никогда не сможет складывать (дедуплицировать) зависимости, чтобы совместимые диапазоны версий устанавливали только одну версию.

Также, как и в вашем случае использования, если A имеет зависимость B, которая работает только с версией 1.0.0, Пакет A.json должен иметь версию, упомянутую для B как 1.0.0 и не "". Вы всегда можете исправить свой верхний уровень yarn.lock добавить запись для B@ решено 1.0.0 но не рекомендуется вручную исправлять файл yarn.lock, как я уже упоминал выше.

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

Источник
Другие вопросы по тегам