pnpm의 p 는 performant npm
'승진, 성능 기준에 맞는' 즉, '고성능 npm'

🌟 실습

create-react-app with pnpm

얀베리와 다른 매력 pnpm에 대해 알아봅시다
우선 pnpm으로 리액트와 함께 환경을 만들어줍니다.
윈도우 버전 >
우선 sopt폴더에 전 pnpm 폴더를 만들어서 vscode로 열었고 터미널에서 작업을 했습니다.

1. install 'pnpm'

npm install -g pnpm

2. cra

pnpm create react-app pnpm-react --template typescript

3. 그런다음 폴더 구조에서 보이는 Delete node_modules, package-lock.json. 말 그대로 삭제
   -> 이유

🤯 create-react-app을 사용하여 React 프로젝트를 생성하고 pnpm을 설치하고 패키지를 설치하는 과정에서 node_modules 디렉터리와 package-lock.json 파일을 삭제하는 이유는 create-react-app 및 pnpm이 다른 패키지 관리 도구로 작동하고 충돌을 방지하기 위함이다!

🤯 package-lock.json은 npm 또는 yarn의 패키지 관리 도구에서 사용하는 파일로, 패키지 의존성 버전 및 해시 값을 추적하는 데 사용됩니다. pnpm은 이 파일 대신 .pnpm-lock.yaml 또는 .pnpm-workspace.yaml를 사용하여 의존성을 추적합니다.

4. Install Packages using pnpm 을 위해서

cd pnpm-react
pnpm install

pnpm의 강력한 특징 심볼릭 링크가 보인다.
신기방기

5. pnpm start
   
   그 전에 toBeDocument 오류가 뜨는데
   "@types/testing-library__jest-dom": "5.14.5"
   pnpm add -D
   이 명령어를 쓰면 app.test.tsx 오류 없이 가능하다.
   
   성공

🌟 Pnpm - Symbolic links

pnpm는 패키지 의존성을 효과적으로 관리하기 위해 특별한 방식으로 node_modules 구조를 만든다.
우리는 실습을 통해서 이를 확인할 수 있다. 이 구조는 디스크 공간을 절약하면서 중복 의존성을 효율적으로 공유하는 방법을 제공한다.

🤖 하드 링크: node_modules 안에 있는 모든 패키지의 모든 파일은 콘텐츠 주소 지정 저장소에 대한 하드 링크이다.

pnpm은 모든 패키지의 파일을 하드 링크로 저장한다. 이것은 하나의 실제 파일을 여러 패키지가 공유하는 것을 의미한다.
예를 들어, 여러 패키지가 동일한 파일을 사용하면 실제 디스크 공간을 낭비하지 않고 동일한 파일에 대한 여러 하드 링크를 유지한다.

🤖 심볼릭 링크: 하드 링크가 실제 파일을 공유하는 방식이라면, 심볼릭 링크는 중첩된 의존성을 연결하는 방식이다. 중첩된 의존성 관계를 나타내며 실제로 중복된 복사본을 만들 필요가 없다.

이와 같이 .pnpm 폴더 안에 심볼릭 링크가 있다.
pnpm는 의존성을 심볼릭 링크를 사용하여 관리하고 중첩된 의존성 그래프를 효율적으로 구성한다. 따라서 node_modules 디렉토리 내에서 심볼릭 링크로 표시되는 패키지는 실제로 .pnpm 디렉토리 내에서 호스팅되는 의존성인 것.
pnpm/pnpm-react/node_modulse/eslint
🙌 이와 같이 표시되는 것은 pnpm의 저장소 구조를 나타내며, 이 패키지가 프로젝트 내에 직접 복사본을 가지고 있지 않음을 나타낸다. 즉, node_modules/.pnpm 을 가리키는 링크만 있다. 이 패키지는 .pnpm 디렉토리 내에 저장되어 있으며, 여러 프로젝트에서 공유될 수 있도록 심볼릭 링크로 연결된다.
🙌 그렇기에 pnpm은 /.pnpm 이곳을 가상 저장소(virtual-store)라고 부른다.

실제로 노드모듈 안에 eslint가 있다.

🙌 즉 pnpm의 핵심 아이디어 중 하나인 디스크 공간을 절약하고 의존성을 효율적으로 공유하는 것을 나타낸다. 실제로 각 프로젝트에서 동일한 의존성을 복사본으로 가지지 않고 필요한 경우 심볼릭 링크로 연결하여 중복을 방지한다.

💻 정리

정리하면 pnpm은 디스크의 세 위치를 사용하면서 용량을 줄인다.

• 저장소(Content-addressable store): 패키지 파일 원본
• 가상 저장소(virtual store): 저장소의 하드 링크 (.pnpm)
• node_modules: 가상 저장소의 심볼릭 링크

🌟 Pnpm - !flat

pnpm은 평탄하지 않은 node_modules를 갖는다. 이것을 이해해보자

npm의 node_modules구조가 왜 평탄화 구조를 취했냐

평탄한 구조 (Flatten Structure): npm3부터 도입된 이 방식은 모든 패키지를 프로젝트의 루트 node_modules 폴더에 설치한다.
즉, 평탄화 전 구조에서는 노드가 모듈을 불러올 때 경로가 길 경우 윈도우즈 환경에서는 불러오지 못한다. cookie처럼 중첩된 패키지를 노드가 불러오는 경우가 그렇다. cookie안에도 의존성이 있고 그 안의 패키지도 중첩된다면 경로 문자가 길어지게 되는 문제를 해결하고자 평탄화 시켰다.
그럼 모든 패키지가 node_modules 하위에 위치하기에 긴 경로로 인한 문제를 예방한다.

하지만 pnpm은 문제점을 발견했다.
1. 모듈 간 접근 문제 : 평탄화로 인해 모듈 별 비의존 패키지에 접근할 수 있다.
2. 평탄화 알고리즘의 복잡성 : npm이나 yarn이 패키지 의존성을 분석해 평탄하게 만드는 것은 상당히 복잡한 알고리즘이라고 한다. 이는 다양한 버전의 패키지와 의존성 간 충돌을 다루어야 하므로 어려울 수 있다.

pnpm은 심볼릭 링크를 활용해 평탄하지 않은 구조의 문제점들을 해결한다.

예시로 의존성 구조를 같이 살펴보자
< 비평탄한 구조 >

Project Root
│
└── node_modules
    │
    ├── Package A
    │   │
    │   └── Module X
    │
    ├── Package B
    │   │
    │   └── Module X

• "Package A"와 "Package B"는 각자 "Module X"를 포함하는 두 패키지이다.
• "Module X"는 동일한 모듈이지만 별도의 복사본으로 각 패키지 내에 중복으로 존재한다.

문제점 : 이러한 중복은 디스크 공간을 낭비하며 유지 관리가 어려울 수 있다.

< 평탄한 구조 >

• "Package A"와 "Package B"가 "Module X"를 필요로 할 때, pnpm는 모든 패키지를 중첩 구조로 유지한다.

• 각 패키지는 중첩된 의존성 구조를 유지하며 "Module X"는 중첩 폴더 내에 존재한다.

• 이 중첩 구조는 물리적으로 중복을 피하며, 디스크 공간을 절약합니다.

• 그러나 모듈 간의 격리 문제를 해결하기 위해 pnpm는 심볼릭 링크를 사용! 이 링크는 모듈 간의 경로를 연결하며 각 패키지가 필요로 할 때 정확한 모듈에 접근할 수 있다.

💻 정리

결과적으로, 모든 패키지는 중첩 구조로 유지되면서 중복을 피하고 모듈 간의 격리를 보장한다.
이로써 디스크 공간을 절약하고 효율성을 향상시킵니다.