작업 공간
pnpm은 기본적으로 ('multi-package repositories', 'multi-project repositories', 'monolithic repositories'로도 알려진) 모노레포를 지원합니다. 하나의 레포지토리에 다수의 프로젝트가 존재하는 워크스페이스를 생성할 수 있습니다.
A workspace must have apnpm-workspace.yaml file in itsroot. A workspace also may have an.npmrc in its root.
If you are looking into monorepo management, you might also want to look intoBit.내부적으로 pnpm을 사용하는 Bit은 기존에 pnpm/npm/Yarn으로 관리되는 workspace에서 수동으로 이루어지는 많은 일을 자동으로 처리합니다. There's an article aboutbit install that talks about it:Painless Monorepo Dependency Management with Bit.
Workspace 프로토콜 (workspace:)
Iflink-workspace-packages is set totrue, pnpm will link packages from the workspace if the available packagesmatch the declared ranges. For instance,foo@1.0.0 is linked intobar ifbar has"foo": "^1.0.0" in its dependencies andfoo@1.0.0 is in the workspace. However, ifbar has"foo": "2.0.0" in dependencies andfoo@2.0.0 is not in the workspace,foo@2.0.0 will be installed from the registry. 이 동작은 다소 불확실합니다.
Luckily, pnpm supports theworkspace: protocol. 이 프로토콜을 사용한다면, pnpm은 로컬 workspace 바깥의 패키지에서는 작업을 수행하지 않습니다. So, if you set"foo": "workspace:2.0.0", this timeinstallation will fail because"foo@2.0.0" isn't present in the workspace.
This protocol is especially useful when thelink-workspace-packages option isset tofalse. In that case, pnpm will only link packages from the workspace iftheworkspace: protocol is used.
별칭으로 workspace 패키지를 참조하기
Let's say you have a package in the workspace namedfoo. Usually, you wouldreference it as"foo": "workspace:*".
If you want to use a different alias, the following syntax will work too:"bar": "workspace:foo@*".
이 별칭들은 게시되기 전에 별칭이 가리키는 의존성으로 변환됩니다. The aboveexample will become:"bar": "npm:foo@1.0.0".
상대 경로로 workspace 패키지를 참조하기
2개의 패키지가 포함된 workspace에서
+ packages
+ foo
+ bar
bar may havefoo in its dependencies declared as"foo": "workspace:../foo". 패키지를 게시하기 전에 이 설명들은 모든 패키지 관리자가 지원하는 일반 버전 설명으로 변환됩니다.
Workspace 패키지를 게시하기
When a workspace package is packed into an archive (whether it's throughpnpm pack or one of the publish commands likepnpm publish), we dynamicallyreplace anyworkspace: dependency by:
- The corresponding version in the target workspace (if you use
workspace:*,workspace:~, orworkspace:^) - 연관된 시맨틱 범위 (기타 범위 유형의 경우)
So for example, if we havefoo,bar,qar,zoo in the workspace and they all are at version1.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, readthis page.
For using Changesets with pnpm, readthis guide.
Troubleshooting
pnpm은 workspace 의존성에 순환이 있는 경우 스크립트가 토폴로지 순서대로 실행됨을 보장할 수 없습니다. Pnpm이 설치 도중 순환 의존성을 감지하면 경고를 생성합니다. Pnpm이 어떤 의존성이 순환을 야기하는지 찾을 수 있으면 해당 의존성 또한 경고에 보여줍니다.
If you see the messageThere are cyclic workspace dependencies, please inspect workspace dependencies declared independencies,optionalDependencies anddevDependencies.
사용 예
다음은 pnpm의 workspace 기능을 사용하는 가장 인기 있는 오픈 소스 프로젝트 중 일부입니다.