Рабочие пространства Yarn (перевод)

Yarn

version :Yarn 2.x

оригинал:yarn.boot CSS.com/docs/works П…

Начиная с Yarn 1.0, рабочие пространства — это новый способ настройки архитектуры пакета. Это позволяет вам настроить несколько пакетов, так что вам нужно всего лишь один раз запустить yarn install, чтобы установить все пакеты за одну операцию.

Почему вы это делаете?

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

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

  • 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. и рабочее пространство-b используются.

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

Как это по сравнению с Лерной?

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

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

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

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

    workspaces-experimental false

  • Если вы вносите изменения только в одну рабочую область, используйте --focus для быстрой установки родственных зависимостей из реестра вместо того, чтобы создавать их все с нуля.

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

Ваше рабочее пространство и макет пакета, который получат ваши пользователи, будут другими (зависимости рабочего пространства будут переведены в более высокую иерархию файловой системы). Поскольку процесс подъема не стандартизирован, предположения о такой компоновке уже опасны, так что теоретически здесь нет ничего нового. Если у вас есть проблемы, попробуйте вариант nohoist

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

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

С точки зрения иерархии папок, рабочая область должна быть потомком корня рабочей области. Вы не можете и не можете ссылаться на рабочие пространства, которые находятся за пределами этой иерархии файловой системы.

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

Категории