작업 공간
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:)
기본적으로 pnpm은 이용 가능한 패키지 버전이 선언된 범위와 일치하는 경우에 workspace의 패키지를 참조합니다. 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 기능을 사용하는 가장 인기 있는 오픈 소스 프로젝트 중 일부입니다.
프로젝트 | Stars | 마이그레이션 일자 | 마이그레이션 커밋 |
---|---|---|---|
Next.js | 2022-05-29 | f7b81316aea4fc9962e5e54981a6d559004231aa | |
Material UI | 2024-01-03 | a1263e3e5ef8d840252b4857f85b33caa99f471d | |
Vite | 2021-09-26 | 3e1cce01d01493d33e50966d0d0fd39a86d229f9 | |
Nuxt | 2022-10-17 | 74a90c566c936164018c086030c7de65b26a5cb6 | |
Vue 3.0 | 2021-10-09 | 61c5fbd3e35152f5f32e95bf04d3ee083414cecb | |
Astro | 2022-03-08 | 240d88aefe66c7d73b9c713c5da42ae789c011ce | |
n8n | 2022-11-09 | 736777385c54d5b20174c9c1fda38bb31fbf14b4 | |
Prisma | 2021-09-21 | c4c83e788aa16d61bae7a6d00adc8a58b3789a06 | |
Slidev | 2021-04-12 | d6783323eb1ab1fc612577eb63579c8f7bc99c3a | |
Turborepo | 2022-03-02 | fd171519ec02a69c9afafc1bc5d9d1b481fba721 | |
Ember.js | 2023-10-18 | b6b05da662497183434136fb0148e1dec544db04 | |
Element Plus | 2021-09-23 | f9e192535ff74d1443f1d9e0c5394fad10428629 | |
NextAuth.js | 2022-05-03 | 4f29d39521451e859dbdb83179756b372e3dd7aa | |
Qwik | 2022-11-14 | 021b12f58cca657e0a008119bc711405513e1ee9 | |
VueUse | 2021-09-25 | 826351ba1d9c514e34426c85f3d69fb9875c7dd9 | |
SvelteKit | 2021-09-26 | b164420ab26fa04fd0fbe0ac05431f36a89ef193 | |
Verdaccio | 2021-09-21 | 9dbf73e955fcb70b0a623c5ab89649b95146c744 | |
Vercel | 2023-01-12 | 9c768b98b71cfc72e8638bf5172be88c39e8fa69 | |
Vitest | 2021-12-13 | d6ff0ccb819716713f5eab5c046861f4d8e4f988 | |
Cycle.js | 2021-09-21 | f2187ab6688368edb904b649bd371a658f6a8637 | |
Milkdown | 2021-09-26 | 4b2e1dd6125bc2198fd1b851c4f00eda70e9b913 | |
Nhost | 2022-02-07 | 10a1799a1fef2f558f737de3bb6cadda2b50e58f | |
Logto | 2021-07-29 | 0b002e07850c8e6d09b35d22fab56d3e99d77043 | |
Rollup plugins | 2021-09-21 | 53fb18c0c2852598200c547a0b1d745d15b5b487 | |
icestark | 2021-12-16 | 4862326a8de53d02f617e7b1986774fd7540fccd | |
ByteMD | 2021-02-18 | 36ef25f1ea1cd0b08752df5f8c832302017bb7fb |