Робочий простір
pnpm має вбудовану підтримку монорепозиторіїв (також відомих як репозиторії з декількома пакунками, репозиторії з декількома проєктами або монолітні репозиторії). Ви можете створити робочий простір, щоб обʼєднати кілька проєктів в одному репозиторії.
A workspace must have a pnpm-workspace.yaml file in its
root. A workspace also may have an .npmrc in its root.
Якщо ви розглядаєте управління монорепозиторіями, ви також можете розглянути 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 link-workspace-packages is set to true, pnpm will link packages from the workspace if the available packages
match the declared ranges. For instance, foo@1.0.0 is linked into bar if
bar has "foo": "^1.0.0" in its dependencies and foo@1.0.0 is in the workspace. However, if bar has
"foo": "2.0.0" in dependencies and foo@2.0.0 is not in the workspace,
foo@2.0.0 will be installed from the registry. Така поведінка вносить певну невизначеність.
Luckily, pnpm supports the workspace: protocol. При використанні цього протоколу pnpm відмовлятиметься виконувати перетворення на будь-що, окрім пакунків локального робочого простору. So, if you set "foo": "workspace:2.0.0", this time
installation will fail because "foo@2.0.0" isn't present in the workspace.
This protocol is especially useful when the link-workspace-packages option is
set to false. In that case, pnpm will only link packages from the workspace if
the workspace: protocol is used.
Посилання на пакунки робочого простору через псевдоніми
Let's say you have a package in the workspace named foo. Usually, you would
reference it as "foo": "workspace:*".
If you want to use a different alias, the following syntax will work too:
"bar": "workspace:foo@*".
Перед публікацією псевдоніми перетворюються на звичайні залежності від псевдонімів. The above
example will become: "bar": "npm:foo@1.0.0".
Посилання на пакунки робочого простору через їхній відносний шлях
У робочому просторі з 2 пакунками:
+ packages
+ foo
+ bar
bar may have foo in its dependencies declared as
"foo": "workspace:../foo". Перед публікацією ці специфікації перетворюються у звичайні специфікації версій, які підтримуються усіма менеджерами пакунків.
Публікація пакунків робочого простору
When a workspace package is packed into an archive (whether it's through
pnpm pack or one of the publish commands like pnpm publish), we dynamically
replace any workspace: dependency by:
- The corresponding version in the target workspace (if you use
workspace:*,workspace:~, orworkspace:^) - Асоційований діапазон Semver (для будь-якого іншого типу діапазону)
So for example, if we have foo, bar, qar, zoo in the workspace and they all are at version 1.5.0, the following:
{
"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 зможе зʼясувати, які залежності спричиняють цикли, він також покаже їх.
If you see the message There are cyclic workspace dependencies, please inspect workspace dependencies declared in dependencies, optionalDependencies and devDependencies.
Приклад використання
Ось декілька найпопулярніших відкритих проєктів, які використовують функцію робочого простору pnpm:
