Робочий простір
pnpm має вбудовану підтримку монорепозиторіїв (також відомих як репозиторії з декількома пакунками, репозиторії з декількома проєктами або монолітні репозиторії). Ви можете створити робочий простір, щоб обʼєднати кілька проєктів в одному репозиторії.
A workspace must have a pnpm-workspace.yaml file in its root.
If you are looking into monorepo management, you might also want to look into Bit. Bit використовує pnpm під капотом, але автоматизує багато речей, які зараз виконуються вручну в традиційному робочому просторі, керованому pnpm/npm/Yarn. There's an article about bit install that talks about it: Painless Monorepo Dependency Management with Bit.
Протокол робочого простору (workspace:)
If linkWorkspacePackages is set to true, 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" у робочому просторі відсутній.
This protocol is especially useful when the linkWorkspacePackages option is set to 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:
For how to set up a repository using Rush, read this page.
For using Changesets with pnpm, read this guide.
Усунення несправностей
pnpm не може гарантувати виконання скриптів у топологічному порядку, якщо між залежностями робочого простору є цикли. Якщо pnpm виявить циклічні залежності під час встановлення, він видасть попередження. Якщо pnpm зможе зʼясувати, які залежності спричиняють цикли, він також покаже їх.
Якщо ви бачите повідомлення Існують циклічні залежності робочого простору, перевірте залежності робочого простору, оголошені у dependencies, optionDependencies та devDependencies.
Приклад використання
Ось декілька найпопулярніших відкритих проєктів, які використовують функцію робочого простору pnpm:
