작업 공간
pnpm은 기본적으로 ('multi-package repositories', 'multi-project repositories', 'monolithic repositories'로도 알려진) 모노레포를 지원합니다. 하나의 레포지토리에 다수의 프로젝트가 존재하는 워크스페이스를 생성할 수 있습니다.
A workspace must have a pnpm-workspace.yaml file in its
root. A workspace also may have an .npmrc in its root.
If you are looking into monorepo management, you might also want to look into Bit.
내부적으로 pnpm을 사용하는 Bit은 기존에 pnpm/npm/Yarn으로 관리되는 workspace에서 수동으로 이루어지는 많은 일을 자동으로 처리합니다. There's an article about bit install that talks about it: Painless Monorepo Dependency Management with Bit.
Workspace 프로토콜 (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은 로컬 workspace 바깥의 패키지에서는 작업을 수행하지 않습니다. 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.
별칭으 로 workspace 패키지를 참조하기
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".
상대 경로로 workspace 패키지를 참조하기
2개의 패키지가 포함된 workspace에서
+ packages
+ foo
+ bar
bar may have foo in its dependencies declared as
"foo": "workspace:../foo". 패키지를 게시하기 전에 이 설명들은 모든 패키지 관리자가 지원하는 일반 버전 설명으로 변환됩니다.
Workspace 패키지를 게시하기
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:^) - 연관된 시맨틱 범위 (기타 범위 유형의 경우)
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"
}
}
이 기능을 사용하면 로컬 workspace 패키지에 의존할 수 있으면서 동시에 원격 레지스트리에 결과 패키지를 중간 단계없이 게시할 수 있습니다. 패키지 사용자는 다른 패키지처럼 게시된 workspace를 사용할 수 있으며 여전히 시맨틱 제공을 보장받습니다.
릴리즈 워크플로
Workspace 내부에서 패키 지 버전을 관리하는 것은 복잡한 작업이며 pnpm은 현재 내장된 솔루션을 제공하지 않습니다. 하지만 버전 관리를 해결하고 pnpm을 지원하는 2가지 잘 테스트된 도구가 있습니다.
For how to set up a repository using Rush, read this page.
For using Changesets with pnpm, read this guide.
Troubleshooting
pnpm은 workspace 의존성에 순환이 있는 경우 스크립트가 토폴로지 순서대로 실행됨을 보장할 수 없습니다. Pnpm이 설치 도중 순환 의존성을 감지하면 경고를 생성합니다. Pnpm이 어떤 의존성이 순환을 야기하는지 찾을 수 있으면 해당 의존성 또한 경고에 보여줍니다.
If you see the message There are cyclic workspace dependencies, please inspect workspace dependencies declared in dependencies, optionalDependencies and devDependencies.
사용 예
다음은 pnpm의 workspace 기능을 사용하는 가장 인기 있는 오픈 소스 프로젝트 중 일부입니다.
