Робочий простір
pnpm має вбудовану підтримку монорепозиторіїв (також відомих як репозиторії з декількома пакунками, репозиторії з декількома проєктами або монолітні репозиторії). Ви можете створити робочий простір, щоб обʼєднати кілька проєктів в одному репозиторії.
Робоча область повинна мати файлpnpm-workspace.yaml у корені.
Якщо ви розглядаєте управління монорепозиторіями, ви також можете розглянутиBit.Bit використовує pnpm під капотом, але автоматизує багато речей, які зараз виконуються вручну в традиційному робочому просторі, керованому pnpm/npm/Yarn. Є стаття проbit install, яка розповідає про це:Безболісне керування залежностями Monorepo за допомогою Bit.
Протокол робочого простору (workspace:)
ЯкщоlinkWorkspacePackages встановлено уtrue, pnpm буде лінкувати пакунки з робочого простору, якщо доступні пакунки відповідають оголошеним діапазонам. Наприклад,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" у робочому просторі відсутній.
Цей протокол особливо корисний, коли параметрlinkWorkspacePackages має значення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 зможе зʼясувати, які залежності спричиняють цикли, він також покаже їх.
Якщо ви бачите повідомленняІснують циклічні залежності робочого простору (There are cyclic workspace dependencies), перевірте залежності робочого простору, оголошені уdependencies,optionDependencies таdevDependencies.
Приклад використання
Ось декілька найпопулярніших відкритих проєктів, які використовують функцію робочого простору pnpm: