6. Вопросы и ответы

Почему стоит перейти на Yarn Modern?

Хотя Yarn Classic (версии 1.x) остаётся важной частью JavaScript-экосистемы, мы рекомендуем перейти на Modern, если это возможно. Почему?

1. Новые возможности: помимо привычных возможностей Classic, Modern предлагает новые (yarn dlx, встроенный patch: протокол, ...), плагины расширяющие функциональность Yarn с помощью changesets, ограничений, рабочих пространств, ...

2. Эффективность: Modern использует новые стратегии установки, уменьшая размер проектов; например, по умолчанию, исходные артефакты CRA теперь занимают 45 МБ вместо 237 МБ. Также улучшились производительности, большинство установок теперь занимают несколько секунд даже в очень больших проектах. Мы даже сделали возможным достижение нулевых секунд!

3. Расширяемость: архитектура Modern позволяет вам создавать собственные функции по мере необходимости. Больше не нужно ждать, пока мы добавим эту функцию, которую вы хотите – вы можете сделать её сами, в соответствии со своими спецификациями! Направленные рабочие пространства, пользовательские установки, проверка проекта, ...

4. Стабильность: Modern создан после многих лет работы над Classic, что позволило нам исправить давние проблемы в реализации некоторых функций. Рабочие пространства теперь являются основными компонентами, процесс разрешения упрощён, структуры данных более эффективны... в результате Modern гораздо менее подвержен неверным предположениям и другим ошибкам в проектировании.

5. Будущее: одна из главных причин, по которой мы инвестировали в Modern, заключалась в том, что мы заметили, как становится сложно создавать новые функции на Classic – каждое изменение слишком вероятно может иметь непредвиденные последствия. Архитектура Modern училась на наших ошибках и была разработана, чтобы позволить нам создавать функции гораздо быстрее – что подтверждается нашей новой скоростью.

Насколько лёгкой должна быть миграция с Classic на Modern?

Обычно нужно позаботиться о нескольких основных вещах:

1. Изменился формат настроек. Мы больше не читаем файлы .npmrc или .yarnrc, а вместо этого используем настройки из файла .yarnrc.yml.

2. Некоторые сторонние пакеты не корректно указывают свои зависимости и им потребуется помощь через настройки packageExtensions.

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

4. Некоторые инструменты (в основном React Native и Flow) потребуют понижения до стратегии установки node_modules путём установки значения настройки nodeLinker в node-modules. TypeScript не имеет этой проблемы.

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

Какие файлы следует игнорировать в Git?

Если вы используете Zero-Installs:

.yarn/*
!.yarn/cache
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/sdks
!.yarn/versions

Если вы не используете Zero-Installs:

.pnp.*
.yarn/*
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/sdks
!.yarn/versions

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

• .yarn/cache и .pnp.* можно безопасно игнорировать, но вам нужно будет выполнить yarn install для их перегенерации между переключениями веток – в противном случае это было бы необязательно, см. Zero-Installs.

• .yarn/install-state.gz – файл оптимизации, который вам никогда не придётся добавлять в коммит. Он просто хранит точное состояние вашего проекта, чтобы следующие команды могли запуститься, не решая ваши рабочие пространства заново.

• .yarn/patches содержат патчи, которые вы создавали с помощью команды yarn patch-commit. Вы всегда должны держать их в своём репозитории, так как они необходимы для установки зависимостей.

• .yarn/plugins и .yarn/releases содержат версии Yarn, используемые в текущем репозитории (как определено yarn set version). Вам необходимо хранить их с версиями (это предотвращает потенциальные проблемы, если, скажем, два разработчика используют разные версии Yarn с разными функциями).

• .yarn/sdks содержит SDK для редакторов, сгенерированные @yarnpkg/sdks. Решать, хранить ли его в вашем репозитории или нет, вам; если вы этого не сделаете, вам нужно будет выполнить процедуру создания SDK для редактора заново при клонировании проекта. Более подробную информацию см. в разделе SDK для редакторов.

• .yarn/unplugged следует скорее всего всегда игнорировать, так как они обычно содержат зависящие от машины артефакты сборки. Игнорирование их может, однако, помешать работе Zero-Installs (чтобы этого избежать, установите enableScripts в false).

• .yarn/versions используется плагином версий для хранения определений релизов пакетов. Вам необходимо хранить его в своём репозитории.

• yarn.lock всегда необходимо хранить в вашем репозитории (даже если вы разрабатываете библиотеку).

• .yarnrc.yml (и его предшественник .yarnrc) – файлы конфигурации. Они должны всегда храниться в вашем проекте.

Подсказка: Вы также можете добавить файл .gitattributes для идентификации релизов и плагинов как двоичных данных. Таким образом Git не будет отображать огромные различия всякий раз, когда вы добавляете или обновляете их:

/.yarn/releases/** binary
/.yarn/plugins/** binary

Следует ли добавлять файлы lock в репозиторий?

Да.

Файлы lock должны всегда храниться вместе с исходным кодом проекта – независимо от того, пишете ли вы автономное приложение или распределённую библиотеку.

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

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

• Активные разработчики не получат новые версии, если они не удалят свои установленные артефакты (node_modules), что не происходит часто. Проблемы с обновлением зависимостей в основном будут обнаруживаться новыми разработчиками, что не создаёт хорошего первого опыта и может отпугивать их.

• Даже если вы будете делать свежие установки каждую неделю, ваши обновления не будут легко обратимы – как только вы протестируете самые последние пакеты, вы не будете тестировать более старые. Проблемы совместимости всё равно будут существовать, но будут относится к пакетам, которые ранее работали, но вы уже больше не тестируете. Другими словами, тестируя всегда самые последние релизы semver, вы не увидите, если случайно начали использовать функцию, которая раньше была недоступна.

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

Файлы lock необходимо всегда хранить в репозитории. Тестирование непрерывной интеграции хорошая идея, но следует доверить системам непрерывной интеграции. Например, сам Yarn выполняет ежедневные тесты с последними версиями основных открытых фреймворков и инструментов, что позволяет быстро обнаруживать любые проблемы совместимости с новым релизом, гарантируя при этом, что каждый разработчик получит согласованный опыт работы с проектом. Dependabot и Renovate также являются хорошими инструментами, которые отслеживают обновления ваших зависимостей.

Как можно использовать скрипты между рабочими пространствами?

Немногим известная функция Yarn: любой скрипт с двоеточием в имени (build:foo) можно вызывать из любого рабочего пространства. Ещё одна малоизвестная функция: $INIT_CWD всегда будет указывать на директорию, в которой выполняется скрипт. Вместе эти возможности позволяют создавать переиспользуемые скрипты:

{
  "dependencies": {
    "typescript": "^3.8.0"
  },
  "scripts": {
    "g:tsc": "cd $INIT_CWD && tsc"
  }
}

Затем, из любого рабочего пространства, содержащего собственный tsconfig.json, можно вызывать TypeScript:

{
  "scripts": {
    "build": "yarn g:tsc"
  }
}

или если вы хотите использовать только tsc из корневого рабочего пространства:

{
  "scripts": {
    "build": "run -T tsc"
  }
}

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

{
  "scripts": {
    "build": "node ${PROJECT_CWD}/scripts/update-contributors.js"
  }
}

Является ли Yarn проектом Facebook?

Нет.

Несмотря на то, что первую версию Yarn реализовал Себастиан Маккензи во время работы в Facebook, первоначальный дизайн получил отзывы от различных других компаний (таких как Tilde через Йехуду Ката), и проект был переведён в собственную организацию на GitHub. Facebook продолжал вкладывать средства в него в последующие годы (в основном потому, что он оказался критически важным компонентом экосистемы RN), но основные contributions поступали из открытого исходного кода.

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

Почему registry.yarnpkg.com? Facebook отслеживает нас?

Нет.

Когда Yarn был создан, реестр npm обслуживался через Fastly. По всей видимости, это влияло на производительность установки, поэтому первоначальная команда решила сотрудничать с Cloudflare и настроить обратный прокси-сервер, который бы лучше кэшировал запросы перед их возвращением. Эта настройка даже не имела бэкэнда с нашей стороны.

В какой-то момент npm также перешёл на Cloudflare, и мы отключили прокси, заменив его на CNAME (доказательство). Мы всё ещё сохраняем хостнейм по соображениям надёжности — хотя вполне логично, что домен Yarn будет поддерживаться до тех пор, пока Yarn используется, то же самое необязательно для домена npm. Это даёт нам возможность перенаправлять на резервную копию реестра в случае недоступности основного источника.

Хотя мы собираем некоторые основные данные телеметрии на стороне клиента, никакие логи http никогда не могут достигнуть инфраструктуры Yarn, — и тем более Facebook, у которого нет контроля над проектом (см. также Является ли Yarn проектом Facebook?).

Запросы к registry.yarnpkg.com возвращают 404/500/...; он не работает?

Нет.

Как упоминалось в предыдущем разделе, реестр Yarn — это просто CNAME для реестра npm. Поскольку у нас даже нет бэкэнда, любая ошибка сервера может исходить только от реестра npm и, следовательно, должна быть сообщена им и отслеживаться на их странице состояния.

Является ли Yarn быстрее других менеджеров пакетов?

Пожимаю плечами 🤷‍♀️

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

Проще говоря, наши различия заключаются в наших приоритетах. Разные проекты делают разные компромиссы, и именно это происходит здесь. Мы уделяли приоритет рабочим пространствам, потому что считали, что монорепозитории приносят значительную пользу. Мы вложили значительные ресурсы в продвижение Plug'n'Play (включая десятки contributions в сторонние проекты через dozens of contributions to third-party projects), потому что мы считали это важным для экосистемы. В этом основное различие: мы принимаем свои обоснованные решения относительно дорожной карты проекта.

Скорость относительна и временна. Процессы, дорожные карты и основные ценности — вот что остаётся.

Почему TypeScript патчится, даже если я не использую Plug'n'Play?

Поскольку PnP — это стандарт разрешения, отличающийся от Node, инструментам, которые повторно реализуют API require.resolve, необходимо добавить некоторую логику для учёта разрешения PnP. Хотя различные проекты это сделали (например, Webpack 5 теперь поддерживает PnP из коробки), некоторые всё ещё колеблются. В случае с TypeScript мы начали и продолжаем поддерживать запрос на добавление, но команда TypeScript ещё должна его принять. Чтобы разблокировать наших пользователей, мы приняли решение автоматически применять этот запрос к скачанным версиям TypeScript, используя наш новый протокол patch:.

Что теперь ставит вопрос: почему мы всё ещё применяем этот патч, даже когда Plug'n'Play отключён? Основная причина в том, что Yarn нацелен на обеспечение согласованного поведения. Некоторые настройки включают использование node_modules линкера во время разработки (чтобы избежать необходимости настройки SDK редактора SDK) и PnP в производстве (для скорости установки). Если бы мы применяли исправления только при включённом PnP, то кеш пакетов стал бы другим, что, например, сломало бы неизменяемые установки.

Мы могли бы потенциально сделать это настраиваемым с помощью переключателя, но в конечном итоге мы решили, что это не стоит дополнительных настроек:

• Патч TypeScript — это пустая операция, если PnP не включён, поэтому это не должно повлиять на вашу работу (если это происходит, пожалуйста, откройте вопрос)
• Мы надеемся, что в конечном итоге этот PR будет принят в TypeScript, поэтому чем больше мы получим внимания, тем выше будет наша уверенность
• Начиная с Yarn 3+, ошибки встроенных патчей просто игнорируются, и происходит обращение к исходным источникам