Установки без необходимости копирования

Хотя это не функция сама по себе, термин «Установки без необходимости копирования» охватывает множество функций Yarn, нацеленных на одну конкретную цель — сделать ваши проекты максимально стабильными и быстрыми, устранив главный источник энтропии: сам Yarn.

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

Как Yarn влияет на стабильность проекта?

Yarn делает всё возможное, чтобы запуск yarn install дважды давал один и тот же результат в обоих случаях. Основной способ достижения этого — через файл-замочек (lockfile), который содержит всю необходимую информацию для воспроизводимой установки проекта на различных системах. Но достаточно ли этого?

Хотя Yarn делает всё возможное, чтобы то, что работало, продолжало работать, всегда есть вероятность, что будущая версия Yarn введет ошибку, которая помешает установить ваш проект. Или, возможно, ваши производственные среды изменятся, и yarn install больше не сможет записывать в временные каталоги. Или, возможно, сеть откажет, и ваши пакеты больше не будут доступны. Или, возможно, ваши учетные данные изменятся, и вы начнете получать проблемы с аутентификацией. Или... так много вещей может пойти не так, и не все они поддаются нашему контролю.

Обратите внимание, что эти проблемы не уникальны для Yarn — вы можете помнить время, когда npm удалял производственные серверы из-за ошибки, попавшей в одну из версий. Именно это мы и имеем в виду: любой код, который выполняется, — это код, который может потерпеть неудачу. А благодаря закону Мерфи, мы знаем, что то, что может потерпеть неудачу, обязательно в конечном итоге потерпит.

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

Как достичь этого состояния "установки без необходимости копирования", которое вы пропагандируете?

Чтобы сделать проект без необходимости копирования, необходимо иметь возможность использовать его сразу после клонирования. Это очень легко начать с Yarn 2!

• Во-первых, убедитесь, что ваш проект использует Plug'n'Play, чтобы разрешать зависимости через папку кэша, а не из node_modules.

  • Хотя теоретически вы могли бы добавить вашу папку node_modules в репозиторий вместо кэша, на практике node_modules содержит огромное количество файлов, которые часто меняют расположение и мешают оптимизациям Git. В свою очередь, кэш Yarn содержит ровно один файл на пакет, который меняется только тогда, когда меняются сами пакеты.

• Папка кэша по умолчанию хранится в папке вашего проекта (в .yarn/cache). Просто убедитесь, что вы добавили её в свой репозиторий (см. также Офлайн-кэш).

  • Опять же, весь этот рабочий процесс является необязательным. Если в какой-то момент вы решите, что в итоге предпочитаете использовать глобальный кэш, просто включите enableGlobalCache в настройках yarnrc, и всё вернётся в норму.

• При выполнении yarn install, Yarn сгенерирует файл .pnp.cjs. Добавьте его также в свой репозиторий — он содержит дерево зависимостей, которое Node будет использовать для загрузки ваших пакетов.

• В зависимости от того, имеют ли ваши зависимости скрипты установки или нет (мы рекомендуем избегать их, если возможно, и отдавать предпочтение альтернативам на основе wasm), вы также можете добавить записи .yarn/unplugged.

И всё! Отправьте свои изменения в репозиторий, создайте новую ветку где-нибудь и проверьте, работает ли выполнение yarn start (или любого другого скрипта, который вы обычно используете).

Вопросы

Чем это отличается от простого добавления папки node_modules в репозиторий?

Да, очень сильно. Для примера, папка node_modules размером 135к нескомпрессированных файлов (всего 1,2 ГБ) даёт кэш Yarn размером 2к двоичных архивов (всего 139 МБ). Git просто не может поддерживать первый вариант, в то время как второй вполне приемлем.

Другое большое различие — количество изменений. В Yarn 1, при обновлении пакета, приходилось пересоздавать или просто перемещать огромное количество файлов. Когда то же самое происходит при установке в Yarn 2, результат очень предсказуем: ровно один изменённый файл для каждого добавленного/удаленного пакета. Это, в свою очередь, имеет положительные последствия с точки зрения производительности и безопасности, так как вы можете легко найти неверные контрольные суммы на основе отдельных пакетов.

Возможны ли последствия для безопасности?

Обратите внимание, что по своему дизайну эта настройка требует, чтобы вы доверяли людям, которые изменяют ваш репозиторий. В частности, проекты, принимающие PR от внешних пользователей, должны быть внимательны, чтобы убедиться, что PR, изменяющие архивы пакетов, являются надёжными (потому что в противном случае злонамеренный пользователь мог бы отправить PR для новой зависимости, предварительно изменив содержимое её архива). Лучший способ сделать это — добавить этап CI (только для недоверенных PR), который использует флаг --check-cache:

$> yarn install --check-cache

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