본문으로 건너뛰기
버전: 7.x

Workspace

pnpm은 기본적으로 ('멀티패키지 레포지토리', '멀티프로젝트 레포지토리', '단일 레포지토리'로도 알려진) 모노레포를 지원합니다. 하나의 레포지토리에 다수의 프로젝트가 존재하는 작업 공간을 생성할 수 있습니다.

monorepo를 구성하려면 최상위 디렉토리에 pnpm-workspace.yaml 파일 또는 .npmrc 파일이 있어야 합니다.

tip

모노레포의 관리에 대해 더 자세히 알고 싶으면 Bit에 대해 알아보세요. 내부적으로 pnpm을 사용하는 Bit은 기존에 pnpm/npm/Yarn으로 관리되는 workspace에서 수동으로 이루어지는 많은 일을 자동으로 처리합니다. Bit을 소개하는 bit install과 관련된 글(Bit으로 어렵지 않게 모노레포 의존성 관리하기)을 살펴보세요.

Workspace 프로토콜 (workspace:)​

기본적으로 pnpm은 이용 가능한 패키지가 선언된 버젼의 범위와 일치하는 경우에 workspace의 패키지를 참조합니다. 예를 들어, bar의 dependencies와 workspace에 foo@1.0.0이 존재한다면 bar는 foo@1.0.0을 참조합니다 그러나 bar dependencies 항목에 "foo": "2.0.0" 있고 workspace에 foo@2.0.0 이 없으면 레지스트리에서 foo@2.0.0 설치됩니다. 이 동작은 불확실성을 가져옵니다.

다행히도 pnpm은 workspace: 프로토콜을 지원합니다. 이 프로토콜을 사용한다면, pnpm은 로컬 workspace 바깥의 패키지에서는 작업을 수행하지 않습니다. 만약 "foo": "workspace:2.0.0"로 설정되어 있다면 workspace에 "foo@2.0.0" 가 없기 때문에 설치에 실패할 것입니다.

이 프로토콜은 link-workspace-packages 옵션이 false로 설정된 경우에 특히 유용합니다. 이 경우, workspace: 프로토콜을 사용한다면 pnpm은 workspace에 있는 패키지만을 가져올 것입니다.

별칭으로 workspace 패키지를 참조하기​

foo workspace를 포함한 패키지가 있다고 예를 들어봅시다. 보통 "foo": "workspace:*"로 참조하게 됩니다.

별칭을 사용하는 경우, "bar": "workspace:foo@*" 또한 동작합니다.

이 별칭들은 게시되기 전에 별칭이 가리키는 의존성으로 변환됩니다. 위 예시는 "bar": "npm:foo@1.0.0"로 변환됩니다.

상대 경로로 workspace 패키지를 참조하기​

2개의 패키지가 있는 workspace에서:

+ packages
    + foo
    + bar

bar 는 foo를 "foo": "workspace:../foo"로 선언하여 의존성으로 포함합니다. 패키지를 게시하기 전에 이 설명들은 모든 패키지 관리자가 지원하는 일반 버전 설명으로 변환됩니다.

Workspace 패키지를 게시하기​

Workspace 패키지가 (pnpm pack 혹은 pnpm publish에 의해) 아카이브에 패키징된 경우, workspace: 의존성을 아래 다음과 같이 동적으로 바꿉니다.

  • 대상 workspace의 해당 버전 (workspace:*, workspace:~, workspace:^를 사용하는 경우)
  • 연관된 시맨틱 범위 (기타 범위 유형의 경우)

예를 들어 workspace 내부에 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"
    }
}

이 기능을 사용하면 로컬 workspace 패키지에 의존할 수 있으면서 동시에 원격 레지스트리에 결과 패키지를 중간 단계없이 게시할 수 있습니다. 패키지 사용자는 다른 패키지처럼 게시된 workspace를 사용할 수 있으며 여전히 시맨틱 제공을 보장받습니다.

릴리즈 워크플로​

Workspace 내부에서 패키지 버전을 관리하는 것은 복잡한 작업이며 pnpm은 현재 내장된 솔루션을 제공하지 않습니다. 하지만 버전 관리를 해결하고 pnpm을 지원하는 2가지 잘 테스트된 도구가 있습니다.

Rush를 사용하여 레파지토리를 설정하는 방법은 이 페이지를 참고하십시오.

Changesets와 pnpm을 사용하려면 이 가이드를 참고하십시오.

문제 해결​

pnpm은 workspace 의존성에 순환이 있는 경우 스크립트가 토폴로지 순서대로 실행됨을 보장할 수 없습니다. Pnpm이 설치 도중 순환 의존성을 감지하면 경고를 생성합니다. Pnpm이 어떤 의존성이 순환을 야기하는지 찾을 수 있으면 해당 의존성 또한 경고에 보여줍니다.

There are cyclic workspace dependencies라는 메시지가 표시되면 dependencies, optionalDependencies 및 devDependencies에 선언된 workspace 의존성을 검사하십시오.

사용 예​

다음은 pnpm의 workspace 기능을 사용하는 가장 인기 있는 오픈 소스 프로젝트 중 일부입니다.

ProjectStars마이그레이션 날짜마이그레이션 커밋
Next.js2022-05-29f7b81316aea4fc9962e5e54981a6d559004231aa
Vite2021-09-263e1cce01d01493d33e50966d0d0fd39a86d229f9
Nuxt2022-10-1774a90c566c936164018c086030c7de65b26a5cb6
Vue 3.02021-10-0961c5fbd3e35152f5f32e95bf04d3ee083414cecb
Prisma2021-09-21c4c83e788aa16d61bae7a6d00adc8a58b3789a06
Slidev2021-04-12d6783323eb1ab1fc612577eb63579c8f7bc99c3a
Astro2022-03-08240d88aefe66c7d73b9c713c5da42ae789c011ce
Turborepo2022-03-02fd171519ec02a69c9afafc1bc5d9d1b481fba721
Element Plus2021-09-23f9e192535ff74d1443f1d9e0c5394fad10428629
Verdaccio2021-09-219dbf73e955fcb70b0a623c5ab89649b95146c744
NextAuth.js2022-05-034f29d39521451e859dbdb83179756b372e3dd7aa
VueUse2021-09-25826351ba1d9c514e34426c85f3d69fb9875c7dd9
SvelteKit2021-09-26b164420ab26fa04fd0fbe0ac05431f36a89ef193
Cycle.js2021-09-21f2187ab6688368edb904b649bd371a658f6a8637
Vercel2023-01-129c768b98b71cfc72e8638bf5172be88c39e8fa69
Vitest2021-12-13d6ff0ccb819716713f5eab5c046861f4d8e4f988
Milkdown2021-09-264b2e1dd6125bc2198fd1b851c4f00eda70e9b913
Nhost2022-02-0710a1799a1fef2f558f737de3bb6cadda2b50e58f
Logto2021-07-290b002e07850c8e6d09b35d22fab56d3e99d77043
ByteMD2021-02-1836ef25f1ea1cd0b08752df5f8c832302017bb7fb
Rollup plugins2021-09-2153fb18c0c2852598200c547a0b1d745d15b5b487
icestark2021-12-164862326a8de53d02f617e7b1986774fd7540fccd