pnpm 도입기 (feat: 모노 레포)

요즘 모노레포를 사용하기 위해서 turbo repo를 사용하면서 궁합이 좋은 패키지 매니저인 pnpm을 사용해보고 있다.

몇주간 사용하며 느낀 점들을 간단히 공유한다.

 

pnpm을 선택한 이유 

출처 : https://toss.tech/article/node-modules-and-yarn-berry

 

npm과 Yarn은 복잡하게 얽힌 dependency들을 단일 루트 하에 위치시키며(Hoisting) 

라이브러리의 packages.json에 명시된 dependencies들을 몰래 최상위로 호이스팅 시킨다.

그 과정에서 packages.json에 명시되지 않은 라이브러리를 사용 가능한데 이를 유령 의존성(phantom dependency)이라 부른다.

 

실제로 turborepo에서 yarn을 사용해본 결과 jest를 모노레포 A에서만 깔았는데 모노레포 B에서도 사용할 수 있었다.

 

사실 jest는 별 문제가 되지 않지만 만약 실제 사용하는 공통 라이브러리들이 유령 의존성으로 꼬이는 위험한 문제가 있을 수 있다고 판단했다. (실제 일하는곳도 yarn을 쓰는데 비슷한 경우로 가끔 고통받았다..; )

 

이를 해결하기 위한 yarn berry와 pnpm을 조사해보았는데, yarn berry는 git에 지속적인 과부하를 주고, pnpm 대비 사용하기 까다롭겠다는 생각에 결국은 pnpm을 선택했다.

 

pnpm의 장점

모노레포는 모든 라이브러리를 전역에 직접 설치하고 호이스팅하는 대신 

전역 저장소(Virtual Store)에 패키지를 공유하고 symlink로 패키징을 참조하는 방식을 사용한다.

 

 

모노레포를 사용하면서 비슷한 라이브러리를 많이 다운받을텐데  중복된 패키지를 설치하지 않아 저장 공간과 네트워크를 절약할 수 있으며, 파일 복사를 최소화하여 더 빠르게 패키지를 설치할 수 있게 되었다.

 

이 기능을 온전히 사용하기 위해서는 루트 디렉토리의 .npmrc에 

node-linker=isolated

node-linker=isolated라는 옵션을 사용해줘야한다. (기본 default가 isolated이다.)

 

가끔 turbo repo의 quickstart repo에 'node-linker: hoisted'라고 명시되어 있는데 조심해야한다.

hoisted라면 npm, yarn처럼 모든 패키지가 호이스팅되게 동작한다.

 

만약 특정 라이브러리만 호이스팅하고 싶다면? 

아까 예시로 든 jest를 생각해보자. 모든 모노레포에 jest를 깔고 버전을 맞춰준다고 생각해보면 정말 고통일 것 같다.

Jest 관련 레포를 만들고 해당 레포를 이용하여 jest 라이브러리 버전을 공유하고 싶지 않을까?

또한 eslint, prettier도 매번 깔아야할까..?

 

이를 방지하기 위해서 pnpm은 public-hoist-pattern라는 옵션을 .npmrc에 제공한다.

 

public-hoist-pattern​

• Default: ['*eslint*', '*prettier*']
• Type: string[]

public-hoist-pattern[]=*plugin*

(https://pnpm.io/npmrc 에서 발췌)

 

기본적으로 eslint, prettier는 pnpm에서 호이스팅되게 설정되어 있다. 

만약 jest 관련 설정도 호이스팅하고 싶으면 

public-hoist-pattern[]=*jest*

.npmrc에 사용하면 된다.

 

 

reference 

 

 https://toss.tech/article/node-modules-and-yarn-berry