Рабочие области

Рабочие области - новый способ настройки архитектуры пакета, доступный по умолчанию, начиная с Yarn 1.0. Он позволяет вам настроить несколько пакетов таким образом, что вам нужно всего лишь один раз запустить yarn install, чтобы установить всё из них за один проход.

Зачем это делать?

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

  • Все зависимости проекта будут установлены вместе, что даст Yarn больше возможностей для их оптимизации.

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

Как это использовать?

Добавьте следующее в файл package.json. Начиная с этого момента, мы будем называть эту папку «корневым каталогом рабочей области»:

package.json

{
  "private": true,
  "workspaces": ["workspace-a", "workspace-b"]
}

Обратите внимание, что private: true обязательно! Рабочие области не предназначены для публикации, поэтому мы добавили эту меру безопасности, чтобы убедиться, что ничто не может случайно их раскрыть.

После создания этого файла создайте две новые подпапки с именами workspace-a и workspace-b. В каждой из папок создайте по одному файлу package.json со следующим содержимым:

workspace-a/package.json:

{
  "name": "workspace-a",
  "version": "1.0.0",

  "dependencies": {
    "cross-env": "5.0.5"
  }
}

workspace-b/package.json:

{
  "name": "workspace-b",
  "version": "1.0.0",

  "dependencies": {
    "cross-env": "5.0.5",
    "workspace-a": "1.0.0"
  }
}

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

/package.json
/yarn.lock

/node_modules
/node_modules/cross-env
/node_modules/workspace-a -> /workspace-a

/workspace-a/package.json
/workspace-b/package.json

И это всё! Для запроса workspace-a из файла, расположенного в workspace-b, теперь будет использоваться точный код, который в настоящее время находится внутри вашего проекта, а не тот, что опубликован на Github, и пакет cross-env не задвоился, а был помещен в корень вашего проекта и может использоваться как в workspace-a, так и в ` workspace-b`.

Сравнение с Lerna?

Рабочие пространства Yarn - это низкоуровневые элементы, которые могут использовать такие инструменты, как Lerna (и фактически использовать!). Они никогда не будут пытаться поддерживать высокоуровневые функции, которые предлагает Lerna, но, реализуя основную логику разрешения пакетов и построения символических ссылок в самой Yarn, мы верим, что сможем реализовать новый функционал и повысить производительность.

Советы и трюки

  • Поле workspaces представляет собой массив и содержит пути к каждому рабочему пространству. Так как отслеживать каждое из них может быть затруднительно, в этом поле также могут использоваться глобальные шаблоны! Например, Babel ссылается на все свои пакеты с помощью одной директивыpackages/*.

  • Рабочие пространства достаточно стабильны для использования в крупномасштабных приложениях и не должны ничего менять в работе обычных установок, но если вы думаете, что они что-то нарушают, вы можете отключить их, добавив следующую строку в файл Yarnrc:

      workspaces-experimental false
    

Ограничения и предостережения

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

  • В приведенном выше примере, если workspace-b зависит от версии, отличной от той, на которую ссылается workspace-a в package.json, зависимость будет загружена и установлена с Github’а, и не будет связана с локальной версией. Это происходит, из-за того, что некоторым пакетам, на самом деле, нужно использовать предыдущие версии для сборки новых (Babel - одна из них).

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

  • Рабочие пространства должны быть вложенными папками по отношению к корневой папки рабочей области. Вы не можете и не должны ссылаться на рабочее пространство, расположенное за пределами папок рабочей области.

  • Вложенные рабочие пространства в настоящее время не поддерживаются.