Перейти до основного вмісту
Версія: 8.x

Середовище роботи

pnpm має вбудовану підтримку для монорепозиторіїв (відомих також як багатопакетні репозиторії, багатопроектних репозиторіїв або монолітні репозиторії). Ви можете створити робочий простір, щоб об’єднати кілька проєктів в одному репозиторії.

Робочий простір має мати pnpm-workspace.yaml файл у своєму корені. Робоча область також може мати .npmrc у своєму корені.

порада

Якщо ви розглядаєте управління монорепозиторієм, ви також можете розглянути Bit. Bit використовує pnpm під капотом, але автоматизує багато речей, які зараз виконуються вручну в традиційному робочому просторі, керованому pnpm/npm/Yarn. Є стаття про bit install, яка розповідає про це: Painless Monorepo Dependency Management with Bit.

Протокол робочого простору (workspace:)​

By default, pnpm will link packages from the workspace if the available packages match the declared ranges. Наприклад, foo@1.0.0 повʼязано з bar, якщо bar має "foo": "^1.0.0" у своїх залежностях і foo@1.0.0 знаходиться у робочому просторі. Однак, якщо bar має "foo": "2.0.0" у залежностях і foo@2.0.0 відсутній у робочому просторі, foo@2.0.0 буде встановлено з реєстру. Така поведінка вносить певну невизначеність.

На щастя, pnpm підтримує протокол workspace:. При використанні цього протоколу pnpm відмовлятиметься виконувати перетворення на будь-що, окрім пакунків локального робочого простору. Отже, якщо ви задасте "foo": "workspace:2.0.0", цього разу встановлення не вдасться, оскільки "foo@2.0.0" у робочому просторі відсутній.

Цей протокол особливо корисний, коли параметр link-workspace-packages має значення false. У цьому випадку pnpm буде компонувати пакунки з робочого простору лише за умови використання протоколу workspace:.

Посилання на пакунки робочого простору через псевдоніми​

Припустимо, у робочому просторі у вас є пакунок з назвою foo. Зазвичай, ви посилаєтесь на нього як "foo": "workspace:*".

Якщо ви хочете використовувати інший псевдонім, наступний синтаксис також буде працювати: "bar": "workspace:foo@*".

Перед публікацією псевдоніми перетворюються на звичайні залежності від псевдонімів. Вищенаведений приклад стане: "bar": "npm:foo@1.0.0".

Посилання на пакунки робочого простору через їхній відносний шлях​

У робочому просторі з 2 пакунками:

+ packages
    + foo
    + bar

bar може мати foo у своїх залежностях, оголошених як "foo": "workspace:../foo". Перед публікацією ці специфікації перетворюються у звичайні специфікації версій, які підтримуються усіма менеджерами пакунків.

Публікація пакунків робочого простору​

Коли пакунок робочого простору запаковано до архіву (за допомогою pnpm pack або однієї з команд публікації, наприклад pnpm publish), ми динамічно замінюємо будь-яку залежність workspace: на:

  • Відповідну версію у цільовому робочому просторі (якщо ви використовуєте workspace:*, workspace:~ або workspace:^)
  • Асоційований діапазон Semver (для будь-якого іншого типу діапазону)

Наприклад, якщо у робочому просторі є foo, bar, qar, zoo і всі вони мають версію 1.5.0, то наступне:

{
    "dependencies": {
        "foo": "workspace:*",
        "bar": "workspace:~",
        "qar": "workspace:^",
        "zoo": "workspace:^1.5.0"
    }
}

Буде перетворено на:

{
    "dependencies": {
        "foo": "1.5.0",
        "bar": "~1.5.0",
        "qar": "^1.5.0",
        "zoo": "^1.5.0"
    }
}

Ця функція дозволяє вам покладатися на ваші локальні пакунки робочих просторів і водночас публікувати отримані пакунки у віддаленому реєстрі без проміжних кроків публікації — ваші користувачі зможуть використовувати ваші опубліковані робочі простори як будь-які інші пакунки, отримуючи вигоду від гарантій, що їх пропонує Semver.

Процес релізу​

Керування версіями пакунків у робочому просторі є складним завданням, і наразі pnpm не надає вбудованого рішення для цього. Однак є 2 добре протестовані інструменти, які працюють з версіями і підтримують pnpm:

Про те, як налаштувати репозиторій за допомогою Rush, читайте на цій сторінці.

Про використання Changesets з pnpm читайте в цьому посібнику.

Усунення несправностей​

pnpm не може гарантувати виконання скриптів у топологічному порядку, якщо між залежностями робочого простору є цикли. Якщо pnpm виявить циклічні залежності під час встановлення, він видасть попередження. Якщо pnpm зможе зʼясувати, які залежності спричиняють цикли, він також покаже їх.

Якщо ви бачите повідомлення Існують циклічні залежності робочого простору, перевірте залежності робочого простору, оголошені у dependencies, optionDependencies та devDependencies.

Приклад використання​

Ось декілька найпопулярніших відкритих проєктів, які використовують функцію робочого простору pnpm:

ПроєктЗіркиДата міграціїКоміт міграції
Next.js2022-05-29f7b81316aea4fc9962e5e54981a6d559004231aa
Material UI2024-01-03a1263e3e5ef8d840252b4857f85b33caa99f471d
Vite2021-09-263e1cce01d01493d33e50966d0d0fd39a86d229f9
Nuxt2022-10-1774a90c566c936164018c086030c7de65b26a5cb6
Vue 3.02021-10-0961c5fbd3e35152f5f32e95bf04d3ee083414cecb
Astro2022-03-08240d88aefe66c7d73b9c713c5da42ae789c011ce
n8n2022-11-09736777385c54d5b20174c9c1fda38bb31fbf14b4
Prisma2021-09-21c4c83e788aa16d61bae7a6d00adc8a58b3789a06
Slidev2021-04-12d6783323eb1ab1fc612577eb63579c8f7bc99c3a
Turborepo2022-03-02fd171519ec02a69c9afafc1bc5d9d1b481fba721
Ember.js2023-10-18b6b05da662497183434136fb0148e1dec544db04
Element Plus2021-09-23f9e192535ff74d1443f1d9e0c5394fad10428629
NextAuth.js2022-05-034f29d39521451e859dbdb83179756b372e3dd7aa
Qwik2022-11-14021b12f58cca657e0a008119bc711405513e1ee9
VueUse2021-09-25826351ba1d9c514e34426c85f3d69fb9875c7dd9
SvelteKit2021-09-26b164420ab26fa04fd0fbe0ac05431f36a89ef193
Verdaccio2021-09-219dbf73e955fcb70b0a623c5ab89649b95146c744
Vercel2023-01-129c768b98b71cfc72e8638bf5172be88c39e8fa69
Vitest2021-12-13d6ff0ccb819716713f5eab5c046861f4d8e4f988
Cycle.js2021-09-21f2187ab6688368edb904b649bd371a658f6a8637
Milkdown2021-09-264b2e1dd6125bc2198fd1b851c4f00eda70e9b913
Nhost2022-02-0710a1799a1fef2f558f737de3bb6cadda2b50e58f
Logto2021-07-290b002e07850c8e6d09b35d22fab56d3e99d77043
Rollup plugins2021-09-2153fb18c0c2852598200c547a0b1d745d15b5b487
icestark2021-12-164862326a8de53d02f617e7b1986774fd7540fccd
ByteMD2021-02-1836ef25f1ea1cd0b08752df5f8c832302017bb7fb