1. Рабочие пространства

Рабочие пространства — новый способ настройки архитектуры вашего пакета, доступный по умолчанию начиная с 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

Примечание: не ищите /node_modules/workspace-b. Он не будет там, если его не использует какой-либо другой пакет в качестве зависимости.

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

Обратите внимание, что /workspace-a алиасен как /node_modules/workspace-a через символическую ссылку. Именно это позволяет вам требовать пакет, как если бы это был обычный! Также необходимо знать, что используется поле /workspace-a/package.json#name, а не имя папки. Это означает, что если поле /workspace-a/package.json name было "pkg-a", алиас будет следующим: /node_modules/pkg-a -> /workspace-a и вы сможете импортировать код из /workspace-a с помощью const pkgA = require("pkg-a"); (или, возможно, import pkgA from "pkg-a";).

Как это сравнивается с Lerna?

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

Советы и хитрости

Поле workspaces представляет собой массив, содержащий пути к каждому рабочему пространству. Поскольку отслеживание каждого из них может быть утомительным, это поле также принимает шаблоны glob! Например, Babel ссылается на все свои пакеты через одну директиву packages/*.
Рабочие пространства достаточно стабильны для использования в крупных приложениях и не должны менять способ работы обычных установок, но если вы считаете, что они что-то ломают, вы можете отключить их, добавив следующую строку в ваш файл Yarnrc:
```
workspaces-experimental false
```
Если вы вносите изменения только в одно рабочее пространство, используйте –focus, чтобы быстро установить зависимые пакеты из реестра, а не строить все их с нуля.

Ограничения и замечания

Структура пакетов будет отличаться между вашим рабочим пространством и тем, что получат ваши пользователи (зависимости рабочих пространств будут подняты выше в иерархии файловой системы). Предположения об этой структуре уже были небезопасны, так как процесс поднятия не стандартизирован, поэтому теоретически ничего нового. Если у вас возникнут проблемы, попробуйте использовать вариант nohoist
В приведённом выше примере, если workspace-b зависит от другой версии, чем та, которая указана в workspace-a package.json, зависимость будет установлена из npm, а не связана из вашей локальной файловой системы. Это происходит потому, что некоторым пакетам на самом деле нужно использовать предыдущие версии, чтобы построить новые (Babel — один из них).
Будьте осторожны при публикации пакетов в рабочем пространстве. Если вы готовитесь к следующему релизу и решили использовать новую зависимость, но забыли объявить её в файле package.json , ваши тесты могут всё ещё проходить локально, если другой пакет уже загрузил эту зависимость в корень рабочего пространства. Однако это будет сломано для потребителей, которые получают её из реестра, так как список зависимостей теперь неполный, поэтому у них нет способа скачать новую зависимость. В настоящее время нет способа выдать предупреждение в такой ситуации.
Рабочие пространства должны быть потомками корня рабочего пространства в терминах иерархии папок. Вы не можете и не должны ссылаться на рабочее пространство, которое расположено за пределами этой иерархии файловой системы.
Вложенные рабочие пространства в настоящее время не поддерживаются.