Skip to content

Bun поддерживает workspaces в package.json. Рабочие области упрощают разработку сложного программного обеспечения как монорепозитория, состоящего из нескольких независимых пакетов.

Обычно монорепозиторий имеет следующую структуру:

txt
<root>
├── README.md
├── bun.lock
├── package.json
├── tsconfig.json
└── packages
    ├── pkg-a
    │   ├── index.ts
    │   ├── package.json
    │   └── tsconfig.json
    ├── pkg-b
    │   ├── index.ts
    │   ├── package.json
    │   └── tsconfig.json
    └── pkg-c
        ├── index.ts
        ├── package.json
        └── tsconfig.json

В корневом package.json ключ "workspaces" используется для указания, какие подкаталоги должны считаться пакетами/рабочими областями в монорепозитории. Обычно все рабочие области помещаются в каталог с именем packages.

json
{
  "name": "my-project",
  "version": "1.0.0",
  "workspaces": ["packages/*"],
  "devDependencies": {
    "example-package-in-monorepo": "workspace:*"
  }
}

NOTE

**Поддержка glob** — Bun поддерживает полный синтаксис glob в `"workspaces"`, включая негативные шаблоны (например, `!**/excluded/**`). Полный список поддерживаемого синтаксиса см. [здесь](/ru/runtime/glob#supported-glob-patterns).
json
{
  "name": "my-project",
  "version": "1.0.0",
  "workspaces": ["packages/**", "!packages/**/test/**", "!packages/**/template/**"]
}

Каждая рабочая область имеет собственный package.json. При ссылке на другие пакеты в монорепозитории в качестве поля версии в вашем package.json можно использовать semver или протоколы рабочей области (например, workspace:*).

json
{
  "name": "pkg-a",
  "version": "1.0.0",
  "dependencies": {
    "pkg-b": "workspace:*"
  }
}

bun install установит зависимости для всех рабочих областей в монорепозитории, дедуплицируя пакеты, если это возможно. Если вы хотите установить зависимости только для конкретных рабочих областей, можно использовать флаг --filter.

bash
# Установить зависимости для всех рабочих областей, начинающихся с pkg-, кроме pkg-c
bun install --filter "pkg-*" --filter "!pkg-c"

# Также можно использовать пути. Это эквивалентно команде выше.
bun install --filter "./packages/pkg-*" --filter "!pkg-c" # или --filter "!./packages/pkg-c"

При публикации версии workspace: заменяются на версию package.json пакета,

"workspace:*" -> "1.0.1"
"workspace:^" -> "^1.0.1"
"workspace:~" -> "~1.0.1"

Установка конкретной версии имеет приоритет над версией package.json пакета,

"workspace:1.0.2" -> "1.0.2" // Даже если текущая версия 1.0.1

Рабочие области имеют несколько основных преимуществ.

  • Код можно разделить на логические части. Если один пакет зависит от другого, вы можете просто добавить его как зависимость в package.json. Если пакет b зависит от a, bun install установит ваш локальный каталог packages/a в node_modules вместо загрузки его из реестра npm.
  • Зависимости можно дедуплицировать. Если a и b имеют общую зависимость, она будет поднята в корневой каталог node_modules. Это уменьшает избыточное использование диска и минимизирует проблемы «ада зависимостей», связанные с одновременной установкой нескольких версий пакета.
  • Запуск скриптов в нескольких пакетах. Вы можете использовать флаг --filter для легкого запуска скриптов package.json в нескольких пакетах вашей рабочей области или --workspaces для запуска скриптов во всех рабочих областях.

Обмен версиями с каталогами

Когда многим пакетам требуются одинаковые версии зависимостей, каталоги позволяют вам определить эти версии один раз в корневом package.json и ссылаться на них из ваших рабочих областей с помощью протокола catalog:. Обновление каталога автоматически обновляет каждый пакет, который ссылается на него. Подробности см. в Каталоги.

NOTE

⚡️ **Скорость** — Установки быстрые, даже для больших монорепозиториев. Bun устанавливает монорепозиторий [Remix](https://github.com/remix-run/remix) примерно за `500 мс` в Linux.
  • В 28 раз быстрее, чем npm install
  • В 12 раз быстрее, чем yarn install (v1)
  • В 8 раз быстрее, чем pnpm install

Bun от www.bunjs.com.cn